The choice between AVIF and WebP is not "which format wins" — it is whether the extra 20–25% byte saving justifies adding a second encoded variant to your pipeline. WebP already beat JPEG; AVIF beats WebP by a narrower margin at a steeper cost. The spec table above lists the raw differences. This page does the arithmetic those numbers leave out: how big the real-world win is, what it costs to capture, and which sites should bother.
How much smaller AVIF actually is than WebP
AVIF produces files roughly 20–25% smaller than WebP at matched perceptual quality on photographs. Independent 2026 benchmarks from Cloudinary and the pixotter 2026 benchmark cluster around this figure, with peaks of 30% on noisy, high-frequency content.
The win is not uniform. It tracks the content type:
- Skin texture, foliage, sky gradients — AVIF leads by 25–30%, because AV1's block partitioning preserves fine detail at a tight bitrate.
- Heavily compressed thumbnails (q≈65) — AVIF leads most here, often a 30% reduction.
- Flat UI screenshots, logos, line art — the gap collapses to under 10%; WebP's simpler entropy coder is nearly as efficient.
- Near-lossless heroes (q≈92) — the gap narrows to ~15%, since both codecs converge toward the source.
The strategic point: AVIF's advantage is largest exactly where WebP's was already largest. The first migration step, Convert JPG to AVIF, removes about half the JPEG bytes. The second step, WebP to AVIF, removes a further fifth. Each step delivers a smaller absolute saving than the one before.
What capturing that saving costs
The 20–25% does not come free. AVIF encoding runs 5–20× slower than WebP at comparable effort. A 1200×800 photo that encodes as high-effort WebP in ~200ms can take 5–20 seconds as high-effort AVIF. Decoding is also slower, most visibly on budget Android CPUs where decode time can claw back part of the transfer saving.
Three numbers govern whether the cost is tolerable:
- Asset count — 30 hero images encode once, overnight, painlessly. 30,000 build-time images turn a 2-minute build into a 40-minute one.
- Encoder speed setting —
avifenc --speed 8cuts encode time by an order of magnitude while keeping most of the size lead. The AVIF Compression Settings guide maps the speed-vs-size curve. - Target-device decode — measure on a real low-end phone, not a synthetic Lighthouse run, before assuming the byte saving translates to a faster render.
The browser support gap is small but real
WebP reaches ~96–97% of global users; AVIF reaches ~94–95%. That ~3-point gap, per caniuse: AVIF and caniuse: WebP, is the only support difference that matters in 2026.
The tail differs by who is in it. WebP's holdouts are essentially extinct. AVIF's holdouts are concentrated:
- iOS 15 and older — Safari added AVIF in version 16 (September 2022); WebP arrived in Safari 14 (2020).
- Locked-down corporate Windows builds and some in-app webviews.
Both formats need the same fallback chain regardless, so the gap rarely changes a decision. The AVIF Browser Support guide covers the edge cases. For the underlying format details, see AVIF Format and WebP Format.
The one capability WebP cannot match
AVIF carries 10-bit and 12-bit colour with HDR; WebP is 8-bit only. This is the single decision that is not a tradeoff. WebP physically cannot represent a Display P3 or BT.2020 image with PQ/HLG transfer.
For HDR product photography, cinematic stills, and any content aimed at modern HDR displays, AVIF is the only viable web format. WebP is not an option, so there is no fallback debate — the JPEG below it simply renders in SDR. Gradient-heavy artwork also benefits: 10-bit depth suppresses the banding that 8-bit WebP introduces in skies and soft shadows.
When shipping both formats makes sense
Ship AVIF and WebP together when a CDN absorbs the encoding cost or the asset count is small enough to encode once. The <picture> element negotiates with zero JavaScript: the browser takes the first <source> whose type it supports.
<picture>
<source type="image/avif" srcset="/photo.avif" />
<source type="image/webp" srcset="/photo.webp" />
<img
src="/photo.jpg"
alt="Mountain lake at dawn"
width="1200"
height="675"
loading="lazy"
decoding="async"
/>
</picture>
AVIF-capable browsers (Chrome 85+, Firefox 93+, Safari 16+) take the first source. The ~3% without AVIF fall through to WebP. The vanishing fraction without either gets JPEG. Order is load-bearing: the AVIF source must come first, because the browser stops at the first match.
The cost is variant sprawl. Three formats across four responsive widths is 12 files per source image. Storage and build time scale linearly, which is why a format-negotiating CDN — Cloudflare, Cloudinary, Imgix, Vercel — is the clean way to ship both. See AVIF Optimization for the delivery pipeline and Core Web Vitals & Images for measuring the LCP impact.
Recommendations by site type
The right answer depends on who encodes your images and how many there are.
- New site on a modern image CDN — ship AVIF first, WebP fallback, JPEG last. The CDN encodes and caches on demand, so the encode cost is invisible. This is the 2026 default.
- Existing WebP-only site, build-time pipeline — adding AVIF buys ~20% on already-small files. Often the bigger Core Web Vitals wins are correct dimensions and lazy loading, not a second codec.
- Static-site generator with thousands of images — measure build time honestly. If AVIF doubles the build for an 8% per-image saving, skip it or use
--speed 8. - HDR or gradient-heavy content — use AVIF. WebP cannot carry the dynamic range, so there is no contest.
- Low-end mobile audience — test decode on real devices; the transfer saving can be offset by slower decode on weak CPUs.
For the legacy-format comparisons, see AVIF vs JPG and AVIF vs PNG.
Common questions
Should I drop WebP once I add AVIF?
No. Keep WebP as the fallback. The ~3% of users without AVIF — mostly iOS 15 and older — still support WebP, so dropping it pushes them all the way down to JPEG and loses the saving on that slice. WebP costs one extra <source> line.
Is the 20% saving worth a second build pipeline?
Only if encoding is cheap for you. On a CDN that auto-converts, AVIF is effectively free — enable it. On a build-time pipeline processing thousands of images, the encode time is real; weigh it against the per-image saving before committing.
Are AVIF and WebP technically related?
No. WebP derives from Google's VP8 video codec (2008); AVIF derives from AOMedia's AV1 codec (2018). They share only the <picture> delivery pattern. AVIF's decade-newer codec lineage, not any shared design, accounts for its compression lead.
Convert to AVIF now
These converters run entirely in your browser — the image never leaves your device:
Sources and further reading
- AVIF support tables — caniuse
- WebP support tables — caniuse
- WebP vs AVIF 2026 benchmark — pixotter
- AVIF Format — the technical detail behind the AV1 still image
- Lossy vs Lossless Compression — choosing a compression mode