AVIF has been available since 2020, but it's only in 2026 that it became the obvious default choice for web images. Browser support crossed 94.9%, Google officially recommends it in PageSpeed Insights, and the compression advantages over JPG are too large to ignore. Here's what you need to know.
What is AVIF?
AVIF (AV1 Image File Format) is an image format developed by the Alliance for Open Media — a consortium that includes Google, Apple, Mozilla, Microsoft, and Netflix. It uses the AV1 video codec to compress images, which is why it achieves compression rates that traditional image codecs like JPG can't match.
AV1 was designed for video — it's optimized for the kind of complex, natural content that appears in photos and real-world scenes. When you use it for a single image frame instead of a video stream, you get dramatically better compression than JPG's DCT-based algorithm, which dates back to 1992.
The compression numbers
At equivalent visual quality (measured by SSIM/DSSIM), AVIF consistently beats JPG by 40–60%:
| Format | File size vs JPG | Browser support |
|---|---|---|
| JPG | Baseline | All browsers & apps |
| WebP | ~30% smaller | 95.67% |
| AVIF | ~50% smaller | 94.9% |
| JPEG XL | ~45% smaller | 14.7% (Safari only) |
A real example from my own testing with libvips:
- JPEG (q80): 540 KB
- WebP: 350 KB (−35%)
- AVIF: 210 KB (−61%)
That's not a cherry-picked example — Netflix's internal benchmarks across a diverse image dataset showed AVIF achieving ~50% better compression than JPG on average.
Why AVIF wins over WebP in 2026
WebP was Google's previous recommendation and it's still a solid format. But AVIF has caught up in browser support (94.9% vs 95.67%) while delivering meaningfully better compression.
The gap matters at scale. If you have 1,000 product images averaging 400 KB as JPG:
- WebP: ~270 KB each → 270 MB total
- AVIF: ~200 KB each → 200 MB total
That's 70 MB less bandwidth per 1,000 images served. For high-traffic sites, this compounds into significant CDN cost savings and faster page loads.
Core Web Vitals impact
Largest Contentful Paint (LCP) measures how quickly the main image on a page loads. It's a Google ranking signal and one of the Core Web Vitals metrics.
Large images are the most common cause of poor LCP scores. Switching from JPG to AVIF typically reduces image payload by 40–60%, directly improving LCP. Google's PageSpeed Insights will flag JPG images as a performance opportunity and explicitly recommend AVIF as the preferred replacement.
For e-commerce sites where product images are the LCP element, converting to AVIF is the highest-impact single change for page performance.
Browser support in 2026
AVIF achieved Baseline status in 2024:
- Chrome 85+ (2020)
- Firefox 93+ (2021)
- Safari 16+ (2022)
- Edge 121+ (2024)
The ~5% without support is primarily legacy mobile browsers and Internet Explorer. For most sites, you can serve AVIF as the primary format with a JPG fallback using the HTML <picture> element:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="description">
</picture>
Browsers download only the first format they support.
The encoding speed problem
AVIF's biggest practical limitation is slow encoding. While JPG encodes in ~2ms and WebP in ~168ms, AVIF takes 1–2 seconds per image with the libaom reference encoder.
This makes real-time AVIF encoding impractical for user-uploaded content without a job queue. For static assets (product photos, blog images, landing page assets), encode offline during your build process and serve the pre-encoded AVIF files.
Alternative encoders help:
- rav1e — faster than libaom, slightly larger files
- SVT-AV1 — good balance of speed and compression
In my Rust + libvips backend for Convertify, I use libvips's built-in AVIF support which wraps libaom. For batch conversion of user files, the encoding time is acceptable. For real-time conversion of large files, it's a constraint worth planning around.
AVIF transparency and animation
Unlike JPG, AVIF supports full alpha channel transparency. This makes it a potential replacement for PNG in web contexts — smaller files with the same transparency support.
AVIF also supports animation, making it an alternative to GIF. Animated AVIF files are significantly smaller than GIF while supporting a full color range (GIF is limited to 256 colors).
What about JPEG XL?
JPEG XL (JXL) is technically superior to AVIF in some dimensions:
- Better compression at high quality settings (~20% smaller than AVIF)
- Progressive decoding (shows usable image with 1% of data loaded)
- Lossless JPEG transcoding (20% smaller, byte-perfect reconstruction)
The problem is browser support: 14.7% as of early 2026, limited to Safari 17+.
The big news: Chrome Canary 145 shipped a Rust-based JXL decoder in late 2025, reversing Google's 2022 decision to remove JXL support. Realistic stable Chrome support: H2 2026.
My recommendation: Use AVIF now. Watch JXL for H2 2026 when Chrome stable support arrives. Don't wait.
Practical implementation
For static sites: Convert during build. Store both AVIF and JPG. Use <picture> for fallback.
For CDNs: Cloudflare, Cloudinary, and Imgix serve AVIF automatically via Accept header negotiation. Upload once, let the CDN handle format selection.
For Next.js: The <Image> component serves AVIF automatically for supported browsers since Next.js 13.
For WordPress: ShortPixel, Imagify, and WebP Express all support AVIF conversion.
For manual conversion: Tools like Convertify handle batch AVIF conversion without requiring local tooling.
Summary
AVIF is the right default for web images in 2026:
- ✅ 94.9% browser support — effectively universal with JPG fallback
- ✅ ~50% smaller than JPG at the same quality
- ✅ Recommended by Google PageSpeed Insights
- ✅ Transparency and animation support
- ⚠️ Slow encoding — plan around it for real-time use cases
- ⚠️ Limited app support outside browsers
The implementation is straightforward. The performance gains are significant. There's no good reason to keep shipping JPG for web images in 2026.
Top comments (0)