Why AVIF Beats JPEG and WebP
AVIF stores the same photo as a JPEG at roughly half the bits, and adds HDR, wide color, and transparency. Unlike the format that pioneered the idea, anyone can use it without paying a patent pool. Here's what makes it better, and where it still loses.
A video codec in a photo's clothing
AVIF is the AV1 Image File Format: a still image encoded as a single AV1 intra frame, wrapped in a HEIF-derived ISO-BMFF container, the same container family as HEIC and MP4. The recipe is familiar because Apple's HEIC works exactly the same way with the HEVC codec, and HEIC proved the idea works. Modern video compression, applied to a single frame, beats a 1992-era still format comfortably. What HEIC could not do was ship on the open web, because HEVC's competing patent pools made browser vendors walk away.
AVIF is the industry's answer to that failure. The Alliance for Open Media (founded by Google, Netflix, Mozilla, Amazon, Cisco, Microsoft, Intel and others, with Apple joining in 2018) built AV1 and AVIF to be royalty-free by design; the entire point of the alliance is a codec nobody has to license. So AVIF carries the same compression idea as HEIC without the legal problem that kept HEIC out of browsers.
Where the savings come from
JPEG compresses every 8x8 block of an image independently, from scratch. AV1 brings three decades of newer ideas to the same job.
- It predicts before compressing. Each block is predicted from its already-decoded neighbors using many directional prediction modes, plus chroma-from-luma prediction that infers color from brightness. Only the difference between prediction and reality gets stored, so smooth gradients and repeating textures nearly vanish from the file.
- Its partitioning is flexible. Instead of a fixed grid, AV1 works in superblocks up to 128x128 pixels, subdivided down to 4x4 where the image demands it, so flat sky costs almost nothing while detail gets the bits.
- Its entropy coding is newer. A multi-symbol arithmetic coder squeezes the final bitstream harder than JPEG's Huffman codes.
- It filters inside the decode loop. Filters including CDEF (the constrained directional enhancement filter) clean up compression artifacts as part of decoding, so the encoder can compress harder without visible damage.
- It synthesizes film grain. Random grain is incompressible by definition, so AV1 removes it before encoding, describes it in metadata, and re-synthesizes it on decode. On noisy photographic content this recovers bits that would otherwise be spent storing noise, while keeping the picture's texture.
In practice this adds up to files around 50% smaller than JPEG at equivalent visual quality, and roughly 20–30% smaller than WebP. AVIF is especially strong at low bitrates, the region where JPEG falls apart into visible blocking and WebP smears fine detail into mush; an AVIF at the same rate still looks like a photograph.
The features, side by side
Beyond raw efficiency, AVIF carries capabilities the older formats structurally lack: 10-bit and 12-bit color depth, HDR via the PQ and HLG transfer functions, wide color gamut, full alpha transparency, and animation. JPEG has none of these; WebP has some.
| JPEG | WebP | AVIF | |
|---|---|---|---|
| Typical size vs JPEG | baseline | ~25–30% smaller | ~50% smaller |
| Color depth | 8-bit | 8-bit | 8/10/12-bit |
| HDR (PQ/HLG) | No | No | Yes |
| Transparency | No | Yes | Yes |
| Animation | No | Yes | Yes |
| Progressive rendering | Yes | No | No |
| Encode speed | Fast | Fast | Slow |
| Royalty-free | Yes | Yes | Yes |
| Browser support | Universal | Universal | All current browsers |
Can browsers actually open it?
Yes. This stopped being a real question a while ago. Chrome has supported AVIF since 2020, Firefox since 2021, and Safari since version 16 in 2022 (full support in 16.4). In current browsers, support is effectively universal. That is the crucial difference from HEIC, which after nearly a decade still opens in no major browser at all.
Where AVIF loses
No format wins everything, and AVIF has real trade-offs.
- Encoding is slow, much slower than JPEG or WebP. For a one-off conversion in a browser tool this is irrelevant (a second or two), but at server scale, encoding millions of images, the CPU bill is a genuine line item.
- There is no progressive rendering. A JPEG can paint a blurry preview and sharpen as bytes arrive, while an AVIF shows nothing and then appears all at once when fully decoded. Smaller files soften the blow, but on slow connections JPEG's gradual reveal is a better experience.
- Decoding costs more. On very old or low-end devices without optimized decoders, AVIF takes noticeably more work to display.
- Huge images can show tile seams. Very large images are encoded as a grid of tiles, and early encoders could leave faint seam artifacts at tile boundaries. Modern encoders have largely fixed this, but it is worth knowing the failure mode exists.
- JPEG still wins on compatibility. When you cannot control what opens the file (email attachments, decade-old software, picky upload forms), JPEG remains the safe answer.
What to actually use
The decision is simpler than the comparison table suggests. Use AVIF for web images where you control the pipeline, and serve it with a <picture> fallback where you need one, though in 2026 fallbacks are increasingly optional. Keep JPEG for interchange with unknown recipients: anything you email, attach, or upload to a system you don't control. WebP remains a reasonable middle ground when encode speed matters more than the last 20–30% of savings.
If you want the full mechanics, how the containers are structured and what the codecs actually do to your pixels, the story continues in HEIC and AVIF under the hood.