AVIF (AV1 Image File Format) emerged from the Alliance for Open Media — a consortium including Google, Apple, Mozilla, Netflix, Amazon, and Microsoft. It takes the intra-frame compression from the AV1 video codec and wraps it in a HEIF container for still images. The result is the most efficient image compression available in mainstream browsers.
The numbers are compelling. At equivalent visual quality, AVIF files are typically 50% smaller than JPEG, 20-30% smaller than WebP, and comparable to or better than HEIC — without the patent encumbrance. It supports HDR, wide color gamuts, film grain synthesis, and alpha transparency. The catch is encoding speed: AVIF is painfully slow to encode compared to older formats.
This guide covers the technical architecture, real-world compression comparisons, the browser support timeline, and practical guidance on when to adopt AVIF versus sticking with WebP. Already decided? Convert JPG to AVIF or convert PNG to AVIF right now.
The AV1 Codec Foundation
Understanding AVIF requires understanding AV1. The AV1 video codec was designed by the Alliance for Open Media as a royalty-free alternative to HEVC (H.265). For still images, AVIF uses only AV1's intra-frame coding — the techniques for compressing a single image without reference to other frames.
Superblocks and Partitioning
AV1 divides images into superblocks of 128x128 or 64x64 pixels, then recursively partitions each superblock into smaller blocks using a quad-tree plus binary/ternary split system. The smallest block is 4x4 pixels. This hierarchical partitioning is far more flexible than JPEG's fixed 8x8 blocks or even WebP's 4x4/8x8/16x16 options.
For a portrait photo, the background might use large 64x64 blocks (very efficient), the face might use 16x16 blocks (moderate detail), and the eyes and hair might use 4x4 blocks (maximum precision). The encoder decides automatically based on rate-distortion optimization. This adaptive partitioning is a major contributor to AVIF's compression advantage.
56-Angle Directional Prediction
Before encoding residuals, AV1 predicts each block from neighboring already-decoded blocks. It offers 56 directional prediction angles (compared to JPEG's zero and WebP's ~10). This means textures at virtually any angle — diagonal wood grain, angled text, slanted architectural lines — can be predicted efficiently, leaving only small residuals to compress.
Beyond directional prediction, AV1 includes paeth prediction, smooth prediction, and recursive filter modes. The encoder tests each mode and picks the one that minimizes bitrate for the target quality. More prediction modes means more computation at encode time — this is a major reason AVIF encodes slowly.
Transform and Quantization Pipeline
AV1 supports four transform types (DCT, ADST, identity, and flip-ADST) in sizes from 4x4 to 64x64, and can combine different types for horizontal and vertical dimensions. A block might use DCT horizontally and ADST vertically if that better matches the content. JPEG uses only DCT at 8x8. This flexibility reduces transform noise — the blocky artifacts visible in low-quality JPEGs.
Quantization in AV1 is more fine-grained than JPEG, with per-segment and per-block quantization parameter adjustment. The encoder can allocate more bits to perceptually important regions (faces, text) and fewer bits to regions where artifacts are less visible (uniform backgrounds, motion-blurred areas).
10-Bit, 12-Bit, and HDR: AVIF's Killer Feature
AVIF supports 8, 10, and 12 bits per channel. This is its most significant advantage over WebP (8-bit only) and JPEG (8-bit only).
10-bit (1,024 tones per channel): Eliminates banding in gradients — the visible stepping you see in 8-bit images with smooth sky gradients, studio backdrops, or skin tones. 10-bit AVIF renders these transitions smoothly. This is the sweet spot for high-quality photography on modern displays.
12-bit (4,096 tones per channel): Overkill for most content but valuable for HDR workflows. 12-bit provides the headroom needed for PQ (Perceptual Quantizer) and HLG (Hybrid Log-Gamma) transfer functions used in HDR10 and Dolby Vision content.
Wide color gamut: AVIF supports BT.2020 and Display P3 color spaces natively. Modern phones and monitors (especially Apple's) use P3 or wider gamuts. An AVIF in P3 preserves the vivid reds, greens, and oranges that sRGB JPEG clips. If you've ever noticed that sunset photos look duller on the web than on your phone, color gamut is why.
Film grain synthesis: AV1 can strip film grain during encoding and re-synthesize it during decoding. This is a Netflix contribution — they found that encoding natural film grain wastes bits because grain is random noise that compresses poorly. Synthesizing equivalent grain at decode time produces visually identical results at 20-30% smaller file sizes for grainy content.
Compression Comparison: Real Numbers
Aggregate studies from Netflix, Cloudflare, and Google paint a consistent picture at equivalent SSIM (structural similarity) scores:
| Format | Relative File Size (JPEG = 100%) | Encode Speed |
|---|---|---|
| JPEG (mozjpeg) | 100% | Fast (100-200ms for 12MP) |
| WebP (lossy) | 65-75% | Moderate (300-800ms) |
| AVIF (speed 6) | 45-55% | Slow (2-8s) |
| AVIF (speed 1) | 40-50% | Very slow (15-60s) |
At low bitrates (heavy compression), AVIF's advantage grows. A 30KB AVIF looks noticeably better than a 30KB WebP or 30KB JPEG — fewer block artifacts, better preservation of fine textures, and smoother gradients. This makes AVIF particularly valuable for thumbnail-heavy sites where every kilobyte matters.
At high quality (light compression), the gap narrows. A 500KB AVIF versus a 500KB WebP is hard to distinguish without pixel-peeping. The savings matter most when you're compressing aggressively.
The Encoding Speed Problem
AVIF's biggest practical limitation is encoding speed. The AV1 codec was designed for offline video encoding where a server farm spends hours encoding a movie. Still image encoding inherits this computational complexity.
Speed vs Compression Tradeoffs
AVIF encoders (libaom, libavif, rav1e) offer speed settings from 0 (slowest, best compression) to 10 (fastest, worst compression). The practical range for still images:
- Speed 0-2: Maximum compression. A 12MP image takes 15-60 seconds. Only for build pipelines where you encode once and serve millions of times.
- Speed 4-6: Good balance. 2-8 seconds for 12MP. Suitable for batch processing and CMS uploads.
- Speed 8-10: Fast but compression advantage over WebP shrinks significantly. 200ms-1s. At speed 10, AVIF may actually be larger than optimized WebP.
The sweet spot for most workflows is speed 6: you get 80-90% of the maximum compression benefit at 5-10x the speed of speed 0.
Encoder Implementations
libaom: The reference encoder from Google/AOM. Best compression quality, slowest speed. This is what most tools (Sharp, Squoosh, ImageMagick) use under the hood.
rav1e: Mozilla's Rust-based encoder. Faster than libaom at equivalent speed settings, slightly worse compression. Better for real-time or near-real-time encoding.
SVT-AV1: Intel/Netflix's encoder, optimized for multi-core CPUs. Originally focused on video but increasingly used for still images. Best throughput on machines with many cores.
Browser Support Timeline
AVIF adoption has been gradual but steady:
- Chrome 85 (August 2020): First major browser to ship AVIF support
- Firefox 93 (October 2021): Full AVIF support including animated AVIF
- Samsung Internet 16 (2022): Mobile support for Samsung's large user base
- Safari 16 (September 2022): Apple adds AVIF support in Safari and iOS
- Edge: Follows Chrome (Chromium-based)
As of March 2026, AVIF support covers approximately 93-95% of global browser traffic. The gap versus WebP's 97% comes from older Safari/iOS versions (15.x and below), older Samsung Internet, and niche browsers.
For the remaining ~5%, serve WebP or JPEG as fallback via the <picture> element. The performance overhead of having three sources (AVIF/WebP/JPEG) is near zero since browsers only download the first supported format.
When to Adopt AVIF vs Wait
Adopt AVIF now if you meet these criteria:
- Your build pipeline can handle slower encoding (pre-built assets, CI/CD image optimization)
- You already serve responsive images via
<picture>and have WebP in place - Your audience is primarily on modern browsers (check your analytics — if Safari 15 is still significant traffic, the fallback chain matters more)
- You have high-traffic pages where 30-50% savings on images meaningfully impact performance and bandwidth costs
Wait on AVIF if:
- You need real-time encoding (user uploads, live image processing) — the speed penalty is too high
- Your CMS/CDN doesn't support AVIF yet (though most major CDNs do in 2026)
- You're serving a small number of images where the savings don't justify the build complexity
- Your audience includes significant IE11 or older browser traffic (rare but some industries)
AVIF vs WebP vs JPEG XL vs HEIC
| Feature | AVIF | WebP | JPEG XL | HEIC |
|---|---|---|---|---|
| Compression (vs JPEG) | 50% smaller | 25-35% smaller | 35-40% smaller | 50% smaller |
| Max bit depth | 12-bit | 8-bit | 32-bit float | 10-bit |
| HDR | Yes (PQ, HLG) | No | Yes (PQ, HLG) | Yes (Dolby Vision) |
| Chrome support | Yes (v85+) | Yes (v23+) | Removed | No |
| Safari support | Yes (v16+) | Yes (v14+) | Yes (v17+) | Yes (macOS only) |
| Royalty-free | Yes | Yes | Yes | No (HEVC patents) |
| Encode speed | Slow | Moderate | Fast | Moderate |
| Progressive decode | No | No | Yes | No |
AVIF's position is clear: best compression with HDR support among formats that actually work in Chrome. JPEG XL is technically superior in several dimensions (progressive decoding, lossless JPEG recompression, wider bit depth) but Chrome dropped support in 2023, making it unusable for web delivery. HEIC is patent-encumbered and has no browser support outside Safari on macOS.
Converting To and From AVIF
JPEG to AVIF: The highest-impact conversion. Expect 40-50% file size reduction at equivalent quality. Start with quality 60-70 in AVIF (different scale than JPEG). Convert JPG to AVIF here.
PNG to AVIF: Lossless AVIF is 20-30% smaller than PNG. Lossy AVIF is dramatically smaller for photographic PNGs. Convert PNG to AVIF here.
WebP to AVIF: Expect 15-25% additional reduction over WebP. This is lossy-to-lossy transcoding, so convert from the original source if available. Convert WebP to AVIF here.
AVIF to JPEG: For compatibility when sharing via email, embedding in documents, or printing. Convert AVIF to JPG here.
AVIF to PNG: Lossless conversion for editing or when you need transparency in a universally-supported format. Convert AVIF to PNG here.
AVIF is the most efficient image format you can ship to web browsers in 2026. The 50% savings over JPEG are real, the HDR and wide gamut support future-proofs your assets, and the royalty-free licensing removes legal risk. The encoding speed is a real constraint, but one that's manageable with build-time processing and modern CDN pipelines.
Ready to start? Convert JPG to AVIF, PNG to AVIF, or WebP to AVIF — free, no signup. Or go the other direction: AVIF to JPG and AVIF to PNG for maximum compatibility.