WebP, AVIF, JPEG XL — The Image Codec Changing of the Guard
Three successors clearly beat JPEG on efficiency, and the web is still full of JPEGs. This piece traces where each newcomer came from, why still-image codecs keep getting born out of video codecs, and the structural reason a lingua franca doesn't die just because something faster shows up — down to how you actually compare codecs and ship the files.
A Lingua Franca Doesn't Die of Being Outperformed
English is still the working language of international conferences. Plenty of more regular, easier-to-learn constructed languages have been proposed; none of them took over. Not because they perform worse — because everyone already speaks English.
Image formats work the same way. JPEG is a 1992 standard. Three successors have since arrived that clearly beat it on efficiency. Most photographs on the web are still JPEGs.
This article covers three things in order: what the three newcomers actually are, why still-image codecs keep being born out of video codecs, and why JPEG refuses to die anyway. The internals of JPEG itself — DCT and quantization — are covered in Why JPEG Degrades, so we start from what came next.
Three Newcomers, Three Different Origins
WebP (Google, 2010). Its lossy mode is the keyframe of the VP8 video codec, repurposed as a still-image coder. In 2012 a lossless mode built on an entirely different algorithm was bolted on. So WebP is really one container holding two unrelated codecs.
AVIF (AOMedia, 2019). An AV1 keyframe, wrapped in HEIF (ISOBMFF) — a container that also comes from video. It sits directly downstream of From H.264 to AV1.
JPEG XL (ISO/IEC 18181, 2021–2022). A merger of Google's PIK and Cloudinary's FUIF, designed from scratch for still images. It is the only one of the three that isn't video-derived.
| WebP | AVIF | JPEG XL | |
|---|---|---|---|
| Origin | VP8 keyframe | AV1 keyframe | Purpose-built for stills |
| Bit depth | 8-bit | 8/10/12-bit | High bit depth, HDR |
| Max dimensions | 16383×16383 | AV1 level limits + tiling | Effectively unbounded |
| Where it fits | The baseline you can't skip | The workhorse for web delivery | Archival and print handoff |
Why Still-Image Codecs Come Out of Video
The first frame of a video — the I-frame, or keyframe — cannot reference any previous frame. Turn that around and it's a complete, self-contained still-image codec. Ship a video codec and you get a high-performance image codec as a byproduct.
And that I-frame path carries every optimization the video effort poured into it: recursive block partitioning, dozens of intra-prediction directions, in-loop filters, context-adaptive arithmetic coding. Rebuilding that volume of engineering for stills alone doesn't pay.
The decisive argument, though, is hardware. The biggest obstacle facing any new image format is whether the recipient's device can decode it, and software decoding costs battery and heat. The AV1 decoder already sitting in a phone's SoC handles AVIF almost as-is. Riding along on an existing video decoder is an enormous shortcut on its own. HEIC — the format Apple made the default for photos — follows the same pattern: HEVC I-frames in a HEIF container.
Turn that around and it means the pace of still-image generations is set by video's schedule. Every time video codecs advance a generation, a still-image version arrives with its adoption runway already built. A format that isn't video-derived, by contrast, has to win hardware support and browser implementations entirely on its own. That gap matters later in this article — it is most of the story of where JPEG XL stands today.
"Quality 80" Is Not a Common Unit
Every lossy codec throws information away at the same final step: quantization. The quality parameter decides how coarsely. But the units are unrelated across codecs. There is no correspondence between cwebp -q 80, avifenc -q 80, and cjxl -d 1. They don't even point the same direction — higher -q means better quality in WebP and AVIF, while in JPEG XL a lower -d means better quality.
So "we compared them at the same setting" is not a comparison at all. The only usable rulers are the ones that don't belong to any codec. On the output side, that ruler is bits per pixel (bpp).
is the width in pixels and the height. In words: how many bits, on average, did this image spend per pixel? For the same subject taken to the same apparent quality, the codec with the lower bpp is the stronger one.
Comments
Sign in to comment