AVIF in 2026: the state of the format
29 May 2026
AVIF hit ~94% browser support in 2026 and ships ~50% smaller than JPEG. The honest state of the format — and what to ship today.
AVIF is no longer an early-adopter bet. In 2026 it is the default image codec for new web projects, with the support, tooling, and compression numbers to justify that status. This is a state-of-the-format report: where AVIF won, where it still hurts, and what teams should actually ship this year.
AVIF crossed the adoption threshold
AVIF now reaches roughly 94% of global users, per the AVIF support tables on caniuse. That is the same practical coverage WebP enjoyed when teams adopted it without hesitation. The number matters because format decisions hinge on the tail you have to support, not the majority you already cover.
The turning point was Safari. Apple shipped AVIF in Safari 16 and iOS 16 (September 2022), four years after Chrome. Examples of the holdouts before that date: every iPhone, every iPad, and every macOS browser using WebKit. Once iOS 16 propagated through the install base, AVIF coverage climbed from the high 80s into the mid 90s.
The remaining ~6% are predictable. Examples of the gap: iOS 15-and-older devices, locked-down corporate Windows builds, and some in-app webviews. A fallback covers all of them automatically, so the tail is a solved problem rather than a blocker.
The compression gains are real and measured
AVIF stores a photograph in about half the bytes of a JPEG at matched visual quality. Against WebP, AVIF is a further 20–25% smaller. These are not vendor claims; they hold across 2025–2026 benchmarks measured at matched SSIM quality.
The savings are widest exactly where bytes hurt most. Examples of high-payoff cases: heavily compressed thumbnails, hero images on slow mobile connections, and gradient-heavy graphics where AVIF's wider transform set suppresses banding. At near-lossless quality (q≈90+) the gap narrows, because every modern codec converges there.
If you want to see the difference on identical source images, the side-by-side pages make it concrete: AVIF vs WebP and AVIF vs JPG.
AVIF is now the default, not an opt-in
The clearest sign of maturity is that platforms ship AVIF without asking. Three defaults define 2026:
- Next.js serves AVIF automatically through
next/imagewhen the browser advertises support via theAcceptheader. Settingimages.formatsto["image/avif", "image/webp"]makes AVIF first. - Major CDNs negotiate AVIF on the fly. Examples: Cloudflare Image Resizing, Cloudinary, and Imgix encode and cache AVIF with no frontend change.
- WordPress added native AVIF upload in 6.5 (April 2024), putting the format inside the most common publishing stack on the web.
The practical effect is that many teams already serve AVIF without a deliberate decision. A site on a modern image CDN is likely shipping AVIF to most visitors today.
The frictions that remain
AVIF still has three honest costs, and pretending otherwise wastes engineering time.
Encoding is slow. AVIF encodes 5–20× slower than WebP at comparable effort. A 1200×800 photo that takes ~200ms as high-effort WebP can take 5–20 seconds as high-effort AVIF. The fix is to encode once for static assets, drop the effort level in build pipelines, or offload to a CDN that caches the result. The AVIF Optimization guide covers the speed/quality trade-offs in detail.
Decoding costs more on weak hardware. Decode is heavier than JPEG, most noticeably on low-end mobile CPUs. Transfer savings can be partly offset by decode time on a budget Android device, so measure on real target hardware before assuming a net win on Core Web Vitals.
The JPEG XL contrast. AVIF's rival faster-encoding codec, JPEG XL, still has no broad browser story. Chrome 145 (February 2026) added JPEG XL decoding but kept it behind a flag, per the Chrome platform status entry. Safari enables it by default; Chrome and Firefox do not. That stalled rollout is precisely why AVIF, with its ~94% coverage, remains the safe default for production in 2026.
What teams should ship in 2026
Ship AVIF first, with a WebP or JPEG fallback, using the <picture> element or a framework that handles negotiation for you. The browser picks the first format it understands:
<picture>
<source type="image/avif" srcset="/photo.avif" />
<source type="image/webp" srcset="/photo.webp" />
<img src="/photo.jpg" alt="…" width="1200" height="675" loading="lazy" decoding="async" />
</picture>
This pattern serves AVIF to ~94% of users, WebP to most of the rest, and JPEG to the final sliver — with zero runtime branching in your own code. The AVIF Browser Support guide details the fallback markup.
Keep another format only where AVIF's container overhead loses. Examples: favicons and tiny icons, where the box structure approaches the payload size, and pure vector artwork, where SVG stays sharp and smaller. For everything photographic, AVIF is the 2026 default. Start by reading the full AVIF format overview, or compare it against its closest rival in WebP format.
Convert images to AVIF now
These converters run entirely in your browser — the image never leaves your device: