AVIF has mature browser support: here's when to migrate from WebP

Um post de opinião sobre escassez de hardware reacendeu o debate sobre adotar AVIF em vez de WebP. O suporte de navegador deixou de ser obstáculo há anos; a decisão real agora é de custo e de pipeline.

The trigger: a blog post reignites the discussion

On November 6, 2026, developer Michael Mitchell published an opinion piece asking why hosting providers, social networks like Mastodon and Bluesky, and phone manufacturers don't adopt AVIF for images more broadly. The central argument: with storage costs rising throughout 2026, more efficient formats stopped being a luxury and became a necessity.

Mitchell cites Hetzner as a concrete example: the hosting provider raised prices several times in 2026, attributing the move to rising hardware costs, amplified by demand for AI infrastructure. Against that backdrop, he argues that if YouTube is reportedly already preparing to adopt AV2 (the successor to AV1), possibly in 2027, according to the piece itself, the rest of the internet should also pay closer attention to the image formats already available.

For whoever decides a product's image pipeline, the question is practical, not philosophical: is browser support mature enough to finally abandon JPEG and, more importantly, WebP?

Browser support is no longer the obstacle

The short answer is yes, and has been for a few years. AVIF, a format based on the AV1 video codec, is already natively supported by all the major modern browsers, including Chromium-based browsers, Firefox, and Safari, historically the slowest to adopt new image formats, but one that has also caught up.

As of November 2026, that means practically the entire installed base of modern browsers decodes AVIF natively, with no polyfill or experimental flag required. It's the opposite scenario from what WebP faced in its early years, when Safari was the bottleneck that forced teams to keep a JPEG fallback for far longer than any front-end team would have liked.

In short: the technical risk of adopting AVIF as the primary format has already dropped to nearly zero; what remains to be decided is whether the compression gains are worth the encoding cost in your pipeline.

AVIF vs. WebP: what changes in practice

Mitchell argues that AVIF typically compresses better than WebP while maintaining comparable image quality, which in practice means smaller files without changing the perceived look. It's a view shared by much of the web performance community, although the gain varies depending on the image content: highly detailed photos tend to benefit more than illustrations with few colors, where PNG and lossless WebP still hold their own.

The trade-off, acknowledged by the post's own author, is CPU cost at encoding time: converting an image to AVIF is heavier than generating an equivalent WebP, which weighs especially on services that do on-demand, real-time transcoding for millions of daily uploads.

That leads to the post's central suggestion: instead of forcing hosting providers and social networks to re-encode everything on upload, why not encourage whoever uploads the image to already convert it beforehand, using their own hardware, preserving the original file instead of reconverting it later into a less efficient format? That division of labor is already common practice in front-end build pipelines; it just hasn't reached social networks yet.

How this plays out in builders' day-to-day

For front-end and product teams, the decision to adopt AVIF generally comes down to three fronts:

• Build time, not runtime. Generating AVIF variants during the build, or at the moment of upload to an assets bucket, avoids paying the CPU cost on every request. There are already image conversion libraries and tools, both in Node.js and as command-line and web tools, that support AVIF encoding, which makes it possible to generate these variants without relying on on-demand re-encoding.
• CDN with content negotiation. Image optimization services with a CDN typically offer automatic delivery in the most suitable format for whoever sends the Accept: image/avif header, falling back to WebP or JPEG when the client doesn't support it. That removes from the front-end team the burden of manually maintaining three copies of every image.
• Explicit fallback, when there's no smart CDN. Without a service that negotiates the format automatically, the way forward is the <picture> element:

<picture>
  <source srcset="foto.avif" type="image/avif">
  <source srcset="foto.webp" type="image/webp">
  <img src="foto.jpg" alt="Image description" loading="lazy">
</picture>

The browser picks the first source it supports, from top to bottom, and falls back to the <img> element as a last resort. It's the simplest way to serve AVIF today without giving up compatibility with older browsers or crawlers that still can't decode the format.

The effect on Core Web Vitals

On content and e-commerce sites, images tend to be the biggest contributor to page weight and, often, the element that defines the Largest Contentful Paint (LCP). Swapping a page's hero image or a product banner for an AVIF version, typically smaller than the equivalent WebP depending on the image content, tends to reduce LCP without touching a single line of JavaScript.

That's the least controversial part of Mitchell's argument: fewer bytes traveling arrive faster, cost the provider less bandwidth, and score better on the metrics Google uses to evaluate page experience. The point actually in dispute is different: is it worth forcing this migration at scale, via the platform, or should each site decide this on its own, at its own pace?

Not everyone agrees that's the problem

The post's comment section exposes the most direct counterpoint to Mitchell's argument. An anonymous reader pushed back that storage is still cheap, citing prices around $25 per terabyte for spot drives, enough to store plenty of video regardless of format, and that AV1 and YouTube's future AV2 exist to save bandwidth, not disk space.

Mitchell replied acknowledging the difference between bandwidth and storage, but insisting the problem doesn't disappear: NVMe SSDs, he says, remain expensive and scarce in 2026.

Good conversation, but I think you're missing the broader point of my post. AVIF helps, but it doesn't eliminate these hardware shortages or rising prices.

Michael Mitchell, author of the blog michaelponders.com

Another comment proposes an alternative to AVIF itself: migrating to JPEG XL, which reportedly has a similar compression level but with more features, such as progressive decoding, backward compatibility with legacy JPEG files, and more metadata options. It's a reminder that the image format rivalry doesn't have a single settled winner, even with AVIF ahead on support today.

What this means for whoever decides the pipeline now

Browser support has stopped being an excuse not to use AVIF: that part of the equation has been settled for a few years now. The real decision, in 2026, is about cost and process: who converts the image (the user, the build, the CDN), at what point (upload or build time), and whether it's worth keeping WebP as a middle ground for cases where AVIF's CPU cost still weighs too much. JPEG XL remains a niche alternative, without the same level of browser support that AVIF has already achieved, but it's worth keeping an eye on while the rivalry remains unsettled.