AVIF vs WebP: The Next Format War

For most of the last decade the modern-format question had one answer: use WebP. That is still good advice, but it is no longer the whole picture. AVIF vs WebP is a genuine comparison now — AVIF compresses meaningfully better, and its browser support has crossed the line from experimental to deployable. It also costs more to encode and does not win everywhere. This post gives the honest version of the trade-off, without the inflated numbers that usually accompany a new codec. For the broader format landscape including JPEG, PNG and SVG, start with The Complete Guide to Web Image Formats.

Where Each Format Came From

Both formats are image codecs derived from video codecs, which is why both compress photographs so much better than JPEG.

WebP (Google, 2010) is built on the intra-frame coding of VP8. It has two modes — lossy to replace JPEG, lossless to replace PNG — both supporting 8-bit alpha. Its long deployment history means encoders, editors, CDNs and CMS platforms all handle it reliably.

AVIF (Alliance for Open Media, 2019) is built on the intra-frame coding of AV1, a substantially more advanced codec. AV1's toolbox — more flexible block partitioning, many more intra-prediction modes, better entropy coding — translates directly into smaller files. AVIF also inherits AV1's 10- and 12-bit colour depth, HDR, and wide colour gamut.

Both are royalty-free, so neither carries the licensing baggage that kept JPEG 2000 and HEIC out of the open web.

Compression: The Real Numbers

The honest headline is that AVIF is typically 20–30% smaller than WebP at comparable perceived quality on photographic content. That figure holds up across independent testing, but the spread around it is wide enough that quoting a single number is misleading.

Where AVIF's advantage is largest:

• Photographs at aggressive quality settings. At low bitrates AVIF degrades far more gracefully. Where WebP shows blockiness and colour banding, AVIF tends to smooth instead, so you can push quality lower.
• Noisy or highly detailed images. Foliage, fabric texture, film grain, crowd scenes — AV1's prediction modes handle this content well.
• Images with transparency. AVIF's alpha channel is coded efficiently and often beats lossy WebP with alpha by a wide margin.
• Wide colour and HDR content. WebP cannot represent it at all, so there is no comparison to make.

Where the advantage narrows or disappears:

• Small flat graphics. Icons, simple logos, flat illustrations under a few kilobytes. AVIF's container overhead is larger and lossless WebP is already very efficient on runs of identical colour, so an AVIF icon can genuinely be bigger.
• Screenshots and text-heavy images. Both lossy modes struggle with hard edges. WebP's lossless mode is a clean answer; AVIF's is less mature and often loses.
• Very high quality settings. As you approach visual transparency, the gap compresses considerably.

One subjective caveat is worth stating plainly: AVIF's low-bitrate behaviour is to smooth fine detail rather than break it into blocks. Many people prefer that; some find it produces a waxy, over-denoised look on skin and texture. It is a different failure mode, not strictly a better one — which is why you should look at your own images rather than a chart. The Image Compression & Format Size Estimator reports what each format and quality setting produces for a specific file, computed locally in your browser so the original never leaves your machine.

Browser Support: Close, But Not Equal

This is where WebP retains a real edge, and where a lot of writing overstates AVIF's readiness.

WebP sits at roughly 97% of browsers in use. Every current Chrome, Firefox, Safari and Edge, back several major versions on each.

AVIF sits at roughly 93–95%. Chrome shipped it in 2020, Firefox in 2021, Safari in 16.4 (March 2023), and Edge follows Chrome. The remaining gap is mostly older iOS and macOS Safari versions, some Android webviews, and embedded browsers in apps.

A few percentage points sounds negligible until you translate it: on a site with meaningful traffic, those are real users who would get a broken image rather than a large one. That is not a reason to avoid AVIF — it is a reason not to serve AVIF alone.

Support outside the browser lags further. Many desktop editors, older CMS upload validators, email clients and third-party integrations still reject AVIF, and some reject WebP too. Anything leaving your own site should still be JPEG or PNG, as covered in WebP vs PNG vs JPG.

Encode Time: The Cost Nobody Mentions

AVIF's compression gains are bought with computation. AV1's encoder searches a very large space of partitions and prediction modes to find the smallest representation, and that search is slow.

In practice, AVIF encoding is commonly 5–20x slower than WebP for the same image, depending on the encoder, the speed preset, and how many cores you can throw at it. Modern encoders expose a speed/effort dial, and dropping to a faster preset recovers much of the time at the cost of some of the size advantage.

Encoding a few hundred images at build time in CI is a one-off cost and usually fine. Encoding user uploads on the fly is not: it can add seconds per image, so you will want a queue, a fast preset, or both. Decoding is less of a worry — AVIF decode is fast enough on modern hardware, though somewhat heavier than WebP on very low-end devices.

The Practical Answer: Layer, Don't Choose

The framing of "AVIF vs WebP" implies you must pick one. You do not. The picture element negotiates per browser:

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Product hero" width="1200" height="630">
</picture>

The browser walks the sources in order and takes the first type it understands. Chrome and Firefox get AVIF; older Safari gets WebP; anything ancient gets the JPEG. Order matters — put the most efficient format first.

Always set explicit width and height so the layout reserves space and the optimisation does not cost you a Cumulative Layout Shift penalty.

The downside is that you are now building and storing three versions of every image — a real cost, and the reason to apply the full chain selectively:

• Large photographic images — hero images, LCP elements, gallery shots, anything over ~100KB. These are where 20–30% is worth real bytes. Full AVIF/WebP/JPEG chain.
• Mid-size content images. WebP with a JPEG fallback is usually enough. Adding AVIF is a marginal gain for a doubled build step.
• Icons, logos and diagrams. Use SVG if you have vector artwork. If not, lossless WebP or an optimised PNG; skip AVIF entirely.

A Reasonable Migration Path

If you are on JPEG and PNG today, do not jump straight to a three-format pipeline. The gains are not evenly distributed.

First, resize. Serving a 3000px image into an 800px slot wastes bytes no codec can recover. Downscaling to the largest size actually displayed usually beats any format change on its own.

Second, move to WebP. The biggest single step and the cheapest: roughly 25–35% off photos, often more than half off transparent graphics, at 97% support and fast encodes. Run your originals through the Image Format Helper, which decodes and re-encodes locally in your browser using its own codecs, then tune quality with the Image Compressor, checking the result at full size rather than as a thumbnail.

Third, add AVIF where it pays. Take the handful of large photographic images that dominate your page weight — usually hero and above-the-fold content — and add an AVIF source ahead of the WebP. Measure LCP before and after rather than assuming.

Work from the highest-quality original at every step. Re-encoding an already-compressed JPEG into AVIF stacks lossy quantisation on lossy quantisation; the damage is usually invisible but permanent, which is why a blanket "convert everything" script often disappoints. The same principle applies to any re-encode, as covered in PNG vs JPG.

The Short Version

AVIF compresses better — around 20–30% below WebP on photographs, more at low quality, and it adds HDR, wide colour and higher bit depth that WebP cannot represent. WebP reaches a few percent more browsers, encodes an order of magnitude faster, has more mature tooling, and remains competitive or better on small flat graphics.

Neither replaces the other yet. Serve AVIF first, WebP second, JPEG or PNG last, and apply the full chain to the large photographic images where the extra percentage is worth real kilobytes. If you only do one thing, moving from JPEG to WebP is still the step that removes the most weight for the least effort.