If you've ever wondered whether to use AVIF, WebP, or just stick with JPEG — this is the guide I wish existed when I was building Convertify, a free image converter that handles 20+ formats including all of these.
Let me cut through the noise with actual data.
TL;DR
| Format | Lossy savings vs JPEG | Browser support | Best for |
|---|---|---|---|
| AVIF | ~50% smaller | 94.9% | General web delivery |
| WebP | 25–34% smaller | 95.67% | Fallback, simple graphics |
| JPEG XL | 35–55% smaller | 14.74% (Safari only) | High quality, archival |
| HEIC | ~50% smaller | 12% (Safari only) | Apple ecosystem only |
Recommended today: AVIF → WebP → JPEG fallback chain.
Compression: the real numbers
At equivalent visual quality (measured by SSIM/DSSIM):
- AVIF — ~50% smaller than JPEG (Netflix research, Ctrl.blog 600-image study)
- WebP — 25–34% smaller than JPEG
- JPEG XL — 35–55% smaller than JPEG, but 20% smaller than AVIF at high quality (Cloudinary, 40,000+ image test)
- HEIC — ~50% smaller than JPEG, but patent issues kill web use
Real example — a 2000×2000 product photo:
JPEG (q80): 540 KB (baseline)
WebP: 350 KB (−35%)
JPEG XL: 260 KB (−52%)
AVIF: 210 KB (−61%)
AVIF wins at low-to-medium bitrates. JPEG XL wins at high quality. For most web photography, AVIF is the right call.
Encoding speed matters too
This is where AVIF has a real problem:
| Format | Encoding time (approx) |
|---|---|
| JPEG | ~2.5 ms |
| WebP | ~168 ms |
| JPEG XL | ~seconds (but fast mode available) |
| AVIF | 1–2+ seconds per image |
AVIF is slow to encode. If you're doing batch conversions, you feel this immediately. JPEG XL's encoder was designed for speed — at its default settings it runs ~100× faster than AVIF in throughput while achieving comparable compression.
Decoding matters for users:
- JPEG: ~0.39 ms (fastest)
- WebP: ~24 ms
- AVIF: ~155 ms (5.4× slower than JPEG)
- JPEG XL: similar to AVIF, but with progressive decoding — renders usable preview with just 1% of data downloaded
JPEG XL's progressive rendering is a big deal for large hero images on slow connections. Neither WebP nor AVIF can do this at all.
Browser support in 2026
| Format | Support | Status |
|---|---|---|
| WebP | 95.67% | Baseline "Widely Available" since 2020 |
| AVIF | 94.9% | Baseline 2024, all major browsers |
| JPEG XL | 14.74% | Safari 17+ only, Chrome Canary 145 behind flag |
| HEIC | 12.03% | Safari 17+ only, no other browser plans |
WebP and AVIF are effectively universal. The remaining gaps are legacy browsers — handle them with JPEG fallback.
The big news for JPEG XL: Google reversed its 2022 decision to remove JPEG XL from Chrome. In November 2025, Chrome engineering welcomed a Rust-based decoder contribution. It landed in Chromium Canary 145. Realistic default Chrome support: H2 2026.
HEIC has 12% support entirely from Safari. Chrome, Firefox, Edge — no plans due to HEVC patent complexity. HEIC on the web is dead.
When to use each format
Use AVIF when:
- Serving photos, thumbnails, product images
- You want the best compression for most visitors
- You need animated images (86% smaller than GIF per Google web.dev)
Use WebP when:
- You need the universal fallback behind AVIF
- Simple graphics, logos, illustrations
- You don't have time to think about it
Use JPEG XL when:
- Professional photography workflows (already supported in iPhone 16 Pro ProRAW)
- You need lossless compression (48% smaller than PNG)
- Lossless JPEG transcoding (20% size reduction, byte-perfect reconstruction)
- Wait for Chrome stable before shipping to web visitors
Use HEIC when:
- You're Apple-only (iPhone, Mac, iPad native apps)
- Need to convert for web → convert HEIC to JPG or WebP instantly
What's actually deployed in 2026?
W3Techs data (March 2026):
- PNG: 77.7% of websites
- JPEG: 72.4%
- WebP: 19.4% (1 in 5 sites)
- AVIF: 1.3%
- JPEG XL: < 0.1%
AVIF usage grew 386% between 2022–2024 but still sits at 1.3%. The gap between "supported" and "deployed" is real. CDN auto-negotiation is the fastest path — Cloudflare, Cloudinary, and Shopify's CDN all serve AVIF automatically without you changing a line of frontend code.
The practical implementation
The <picture> element is still the right approach:
If you're using a CDN — just use Accept header negotiation and let the CDN decide.
If you're converting images manually (e.g. iPhone HEIC photos for web), you can do it in one line with libvips (what I use in Convertify's Rust backend):
vips copy input.heic output.avif
Or just use convertifyapp.net — free, no signup, batch up to 10 files. 😄
What's next: AV2 and the Chrome decision
AV2 was announced by Alliance for Open Media in September 2025 — the next-generation codec that will eventually succeed AVIF. 53% of AOM members plan implementation within 12 months of release. Don't hold off on AVIF waiting for AV2 — that's a 2028+ story.
The format landscape for 2026–2027:
- ✅ Ship AVIF + WebP fallback now
- 👀 Watch JPEG XL — Chrome stable target H2 2026
- ❌ Skip HEIC for web — convert it on upload
- 🔭 AV2 — 2028+ horizon
Bottom line
AVIF is the best format for most web images in 2026. Implement it with WebP fallback using <picture>. Use a CDN if you can — it handles everything automatically.
If you're dealing with HEIC files from iPhone or need to convert between formats, check out Convertify — I built it specifically because every other converter was slow or required signup.
What format are you using in production? Drop a comment — curious how many teams have made the jump to AVIF.
Built something with image processing? I'm @app.convertify on X.
Top comments (0)