WebP vs AVIF in 2026: Which to Use for Your Website
Honest 2026 comparison: WebP vs AVIF for web performance, browser support, file size, encoding speed and the practical fallback chain, with real benchmarks.
WebP came out in 2010. AVIF came out in 2019. By 2026, both are mature, both have ~94%+ global browser support, and both crush JPG/PNG on file size. But choosing between them, or how to use both, still trips up developers and content managers. This guide gives you real benchmarks and a clean decision rule.
TL;DR, the 2026 answer
For static sites and pre-built assets: AVIF first, WebP fallback, JPG/PNG last. The <picture> tag handles the chain automatically.
<picture>
<source srcset="/img/photo.avif" type="image/avif" />
<source srcset="/img/photo.webp" type="image/webp" />
<img src="/img/photo.jpg" alt="…" />
</picture>For dynamic resizing, real-time generation or constrained CPU budgets: WebP only. AVIF encoding is too heavy at request time.
The decision in one sentence
If the image is generated once and served forever, use AVIF + WebP fallback. If it's generated per request, use WebP only.
Real benchmarks: same source, both formats
10 representative photos compressed at “visually lossless” quality (SSIM ≥ 0.99 vs original):
| Source (4000×3000 JPG) | JPG q90 | WebP q80 | AVIF q60 | AVIF vs JPG |
|---|---|---|---|---|
| Beach photo (gradient sky) | 2.4 MB | 1.3 MB | 0.7 MB | −71% |
| Portrait (skin tones) | 1.8 MB | 0.9 MB | 0.55 MB | −69% |
| Product on white BG | 1.1 MB | 0.45 MB | 0.28 MB | −75% |
| Cityscape (high detail) | 3.2 MB | 1.8 MB | 1.1 MB | −66% |
| Food photography | 2.1 MB | 1.0 MB | 0.62 MB | −70% |
| Landscape with texture | 2.7 MB | 1.6 MB | 1.0 MB | −63% |
| Logo / illustration | 380 KB | 120 KB | 95 KB | −75% |
| Screenshot (UI) | 540 KB | 210 KB | 165 KB | −69% |
| Fashion (high contrast) | 1.9 MB | 0.95 MB | 0.58 MB | −69% |
| Macro / nature detail | 2.5 MB | 1.4 MB | 0.85 MB | −66% |
| Average | 1.86 MB | 0.97 MB | 0.61 MB | −70% |
For a typical image, AVIF saves ~70% over JPG, ~37% over WebP. The savings are massive at scale: 100 photos = 130 MB JPG, 60 MB WebP, 36 MB AVIF.
Browser support reality check
| Browser | WebP | AVIF | Market share (2026) |
|---|---|---|---|
| Chrome (desktop + Android) | 2014+ | Aug 2020+ | 65% |
| Edge | 2018+ | 2021+ | 5% |
| Firefox | 2019+ | Oct 2021+ | 3% |
| Safari (iOS + macOS) | 2020 (14+) | Mar 2022 (16+) | 19% |
| Samsung Internet | 2019+ | 2021+ | 3% |
| Opera | 2014+ | 2020+ | 2% |
| Old IE / IE Mode | Never | Never | <1% |
| Combined support | ~99% | ~94% | n/a |
The 6% AVIF gap
The 6% without AVIF is mostly: (a) Android < 7 still in use in some regions, (b) old corporate Edge/IE holdouts, (c) embedded WebViews in older apps. Always ship a WebP fallback, it covers all of them.
Encoding speed: the WebP advantage
AVIF compression is heavier because the codec is more complex (HEVC-derived). On a typical workload:
| Operation | WebP (libwebp) | AVIF (libaom) | Difference |
|---|---|---|---|
| 4 MP photo → q80 | 0.8s | 4.2s | 5× slower |
| 4 MP photo → q60 | 0.6s | 3.5s | 5.8× slower |
| 12 MP photo → q80 | 2.1s | 12s | 5.7× slower |
| 100 thumbnails (300×300) | 8s | 38s | 4.7× slower |
| Build entire image library (1000 imgs) | 14 min | 1h 12min | 5.1× slower |
For static-site builds this is fine, encode once, serve forever. For dynamic resizing (e.g. user uploads avatars at request time), the 5× cost is prohibitive.
When to pick WebP
Pick WebP-only when
- You generate images at request time (dynamic resizing)
- Build CPU/time is constrained
- You want simpler tooling (broader library support)
- Your CDN doesn't support AVIF yet
- Your audience skews very-old-Android (regions with old devices)
Pick AVIF + WebP fallback when
- Static site with pre-built assets
- Photo-heavy site (e-commerce, portfolio, news)
- Bandwidth costs matter (CDN bills, mobile users)
- Core Web Vitals are critical (image weight is your bottleneck)
- You can spare build-time CPU
The fallback chain in practice
The HTML <picture> element is the standard way to ship multiple formats. The browser picks the first format it understands.
<picture>
<source type="image/avif" srcset="/img/hero.avif" />
<source type="image/webp" srcset="/img/hero.webp" />
<img src="/img/hero.jpg" alt="Hero image" loading="lazy" />
</picture>Modern frameworks generate this automatically:
| Framework | How |
|---|---|
| Astro | <Image src=... formats={['avif', 'webp']} /> |
| Next.js | next/image + images.formats config |
| Gatsby | gatsby-plugin-image with formats |
| Vite | vite-imagetools plugin |
| Nuxt | @nuxt/image with format array |
| Hugo | Page resources + Resize + Convert |
Don't ship AVIF without WebP
The 6% of users without AVIF support don't see a "broken image", they see nothing. The <picture> tag falls through to the <img> if all <source> entries fail. Always include WebP (or JPG) as the safety net.
Quality knob mapping
The number you put in q= for AVIF doesn’t map to JPG/WebP. Rough equivalents:
| Visual quality | JPG q | WebP q | AVIF q |
|---|---|---|---|
| Almost lossless | 95 | 95 | 80 |
| Visually lossless | 90 | 85 | 65 |
| Sharp at normal viewing | 85 | 80 | 60 |
| Acceptable | 75 | 70 | 50 |
| Visible compression | 60 | 55 | 35 |
| Heavy artefacts | 40 | 35 | 20 |
Default for web: JPG 85, WebP 80, AVIF 60, all produce visually identical output.
Encoding tips for best results
- Always encode from the original (not from a JPG → re-encoded WebP), or you compound losses.
- For photos, use q60 AVIF / q80 WebP, the sweet spot.
- For graphics with sharp edges, switch to lossless WebP or PNG fallback. AVIF lossy can blur fine lines.
- Don’t bother with AVIF for thumbnails under 100×100, the file size difference is tiny vs the encoding cost.
- Strip metadata (EXIF, ICC) when possible, saves another 10–30 KB per image.
What about JPEG XL?
JPEG XL (JXL) is a newer format that some called “AVIF killer” in 2022. As of 2026:
- Chrome removed support in 2023 (controversial decision).
- Safari supports it (since iOS 17).
- Firefox: behind a flag.
Not worth deploying in production yet. The browser support story is too uncertain. Revisit in 2027.
Summary
For 90% of websites in 2026:
- Build pipeline encodes every image to AVIF + WebP + JPG/PNG.
<picture>tag in HTML serves the right one based on browser.- JPG quality 85, WebP 80, AVIF 60 as defaults, visually identical.
- Skip AVIF only for tiny images or dynamic generation paths.
- Measure with Core Web Vitals before and after, image weight should drop ~70%.
You can convert your existing assets right now with JPG to WebP, PNG to WebP, or batch-process via Convert Image. Everything runs locally, no upload, no server.