WebP vs AVIF in 2026: what actually matters for your store

May 18, 2026·5 min read·by Jordan Kim

AVIF encodes smaller files than WebP, but that headline number hides two real concerns for stores: encode time and CDN support. Here is what actually matters in 2026.

Two years ago the answer was "use WebP, AVIF support is patchy." AVIF crossed 90% global browser support sometime in late 2024. That old answer is stale. But the decision for an ecommerce pipeline is still more involved than a caniuse number, and I've watched stores make the wrong call in both directions.

The 2026 recommendation: Use AVIF with a WebP fallback via <picture> for all product images. AVIF runs 30-45% smaller than WebP at equivalent perceptual quality in my testing, and browser support is close enough to universal that the fallback pattern handles the gap cleanly. If your encoding toolchain is stuck on older Sharp versions or you need fast on-demand encoding, WebP at quality 80 is a reasonable interim default. The format debate is largely settled. The harder question is whether your derivative pipeline exists at all.

The formats

WebP is a Google format from 2010, built on VP8 video compression. Lossy and lossless, universal CDN support, encoders that don't surprise you.

AVIF comes from the AV1 video codec, standardized by the Alliance for Open Media in 2019. At equivalent perceptual quality it produces files 30-45% smaller than WebP in my testing on real product images, and it handles HDR, wide color gamut, and alpha channels cleanly.

How does browser support look in 2026?

WebP sits around 97% global support. AVIF is around 93%. The 4-point gap is mostly older Android WebViews and iOS 15-era Safari. That audience shrinks every month and, more importantly, you can serve WebP to them without any real overhead using a standard <picture> element:

<picture>
  <source type="image/avif" srcset="product-1200w.avif 1200w, product-600w.avif 600w" />
  <source type="image/webp" srcset="product-1200w.webp 1200w, product-600w.webp 600w" />
  <img src="product-1200w.jpg" alt="Product name" width="1200" height="900" />
</picture>

The browser picks the first source it can decode. Store both derivatives; the 7% gets WebP automatically. The <picture> element is two extra lines in your markup and zero extra requests for modern browsers.

AVIF file-size advantage

File size is the main event. At quality 60 — a reasonable starting point for product photography — AVIF consistently beats WebP by 30-45% in my testing on real product images. A 200KB WebP becomes roughly a 120KB AVIF. At meaningful traffic volumes, that difference in bandwidth cost adds up fast.

Color accuracy matters for specific product types. AVIF supports 10-bit color natively; WebP is 8-bit. If you're selling paint, textiles, or anything where a customer is making a purchasing decision based on color accuracy on a wide-gamut display, AVIF renders more faithfully. I've flagged this in audits for stores selling furniture and apparel — it's a real issue, not a theoretical one.

Both formats support alpha; the AVIF advantage there is marginal and rarely moves a metric on real product shots.

Where WebP still makes sense

Encode speed is the real friction. libaom, the reference AVIF encoder, is slow. I measured this on a Vercel serverless function while auditing an upload pipeline: a 3.2MP product JPEG encoded to WebP at quality 72 finished in about 180ms. The same image to AVIF at quality 60 took just over 4 seconds. Both looked equivalent at normal viewing sizes.

That 4-second gap matters for on-demand encoding. If you're generating derivatives at upload time in a synchronous path, AVIF will back up your queue under load. The fix is to generate derivatives offline or lazily on first request with aggressive caching — pay once, serve forever. That pattern also makes AVIF's size advantage fully worth it because the encode cost disappears after the first hit.

Check tooling maturity before you commit. Sharp 0.34+ with libheif 1.20 and aom 3.x handles AVIF reliably. Older versions had quality regressions and slower encoders. If your platform pins Sharp to an older version, WebP at quality 80 is a perfectly reasonable default until your toolchain catches up.

Decision checklist for a new pipeline

For a new pipeline in 2026:

Serve AVIF with a WebP fallback via <picture> for all product images.
Generate derivatives offline at upload or lazily on first request with long cache TTLs. Never encode on every page render.
Start at quality 55-65 for AVIF and 70-80 for WebP. The perceptual parity point is lower for AVIF because the codec handles compression artifacts better.
For small thumbnails in image grids, WebP at quality 72 is fine. At 200px wide, the file size delta is 5-10KB and LCP is already dominated by your hero image, not your grid thumbnails.

At Pixel Wand — a DAM built for managing and exporting image assets — WebP handles the library grid thumbnails (640px, quality 72, encoded on upload) because the encode overhead doesn't justify AVIF at that size. The full-resolution export path, where derivatives are cached indefinitely after the first generation request, is exactly where AVIF's size advantage pays off.

JPEG XL: not yet

JXL sits around 75% global support as of mid-2026, has excellent compression, and supports lossless, lossy, and progressive decoding. I wouldn't build a production pipeline around it today: tooling is immature, encode times are worse than AVIF, and the support gap is large enough that the fallback chain gets messy. Worth watching, not worth shipping.

CDN and hosting

Most CDNs doing image optimization now support AVIF output. Cloudflare Images, Fastly, and Imgix all support it. Cloudflare Images will serve AVIF automatically based on the Accept header — if your CDN handles format negotiation, you may not need the <picture> pattern at all.

If you're managing your own R2 or S3 storage and serving derivatives directly, you need the <picture> fallback or a server-side Accept header check.

FAQ

Does AVIF hurt Lighthouse scores if the browser falls back to WebP?

No. Lighthouse measures actual bytes delivered. If an older browser gets a reasonably sized WebP fallback, your score won't drop. The <picture> element adds no render-blocking overhead.

Should I re-encode existing WebP assets to AVIF?

Only if you have the originals. Re-encoding WebP to AVIF compounds generation loss. Always encode from the source JPEG or PNG.

What quality setting should I use for AVIF product photos?

Start at 60. Check at 1x and 2x DPR at your largest display breakpoint. Go to 65 if you see banding on gradients or solid color fields. Down to 50 is reasonable for thumbnails. These numbers interact with image content, so test on your actual catalog — don't just apply a number and ship it.

My image processing library doesn't support AVIF yet.

Sharp 0.34+ supports AVIF encoding via libheif. Upgrade if you can. If you're pinned to an older version, WebP is a legitimate default for now. The quality gap matters most at large display sizes and for color-critical products. For most catalogs, WebP at quality 80 is good enough until you can update your stack.

The format debate is mostly a distraction from the bigger problem: stores still serving full-resolution originals to mobile browsers with no derivatives at all. I've run audits on stores where the hero product image was a 4MB JPEG. Getting that store onto correctly sized WebP derivatives would do more for LCP than any AVIF migration. Fix your derivative pipeline first. Then optimize the format.

Find any asset in seconds. Photo Atlas is digital asset management for creative and brand teams, with early-access founder pricing for the first users. Get early access