How AVIF and JPEG XL actually compress — and why one stalled

Two image formats arrived at roughly the same moment, both promising to retire the quarter-century-old JPEG. Both deliver. AVIF and JPEG XL each produce smaller files at a given visual quality than the baseline JPEG most of the web still runs on, and both carry the features a modern format is expected to have: transparency, high dynamic range, wide color. On the technical merits they are close enough that reasonable engineers disagree about which is better, and for which job.

Yet their fortunes diverged sharply. AVIF ships in every major browser and covers around 94 percent of global users by Can I use’s tally. JPEG XL sits near 15 percent, enabled by default only in Safari, and it got there after being explicitly removed from Chrome. The gap has almost nothing to do with the bitstreams and almost everything to do with who built each one and what they wanted from it. It is worth separating the two stories, because the codec story and the politics story keep getting told as if they were one.

AVIF: a video codec’s still frame

AVIF is, mechanically, a single intra-coded frame of AV1 video wrapped in an ISO base media file (the same HEIF container that holds Apple’s HEIC). AV1 is the royalty-free codec from the Alliance for Open Media, and “intra-coded” means a frame compressed with no reference to any other frame — exactly the problem an image format needs to solve.

The compression comes from AV1’s intra toolset. Where baseline JPEG chops the image into a rigid grid of 8×8 blocks, AV1 starts from superblocks up to 128×128 pixels and recursively splits them down a quad-tree, so a flat sky stays in large blocks while a face full of detail subdivides into small ones. Within each block it predicts pixel values directionally from already-decoded neighbors, transforms the residual, and then runs a deblocking pass plus the Constrained Directional Enhancement Filter to clean up the ringing and blocking artifacts that plague JPEG at low bitrates. The payoff is most visible at the low end: heavily compressed AVIF tends to fail gracefully, going soft rather than blocky.

The feature set inherits from AV1 too. AVIF carries 8-, 10-, and 12-bit depth, HDR through the PQ and HLG transfer functions, and wide color gamut. Transparency is handled by encoding the alpha channel as a second AV1 image item, referenced from the primary one — efficient, though it does mean a transparent image is effectively two coded planes.

AVIF’s weaknesses are the inherited ones. AV1 was tuned for video, where frames are small and plentiful; encoding a single very large still can be slow, and the format has no real progressive mode, so a partially downloaded AVIF shows nothing rather than a coarse preview. For most web imagery, none of that outweighs the bandwidth saved.

JPEG XL: two codecs in one container

JPEG XL was designed from the start as an image format rather than borrowed from a video one, and it is really two compression engines sharing a bitstream. The lossy path, VarDCT, descends from Google’s PIK. Like AV1 it abandons the fixed 8×8 grid, using DCT blocks from 2×2 up to 256×256 and several non-square shapes, and it works in the XYB color space, a perceptual model derived from how human cone cells respond. The lossless and near-lossless path, Modular mode, descends from Cloudinary’s FUIF — itself a descendant of the FLIF lossless format — and handles alpha, extra channels, and a progressive lossy mode built on a reversible “squeeze” transform. An encoder can mix them, using Modular as a sub-stream inside a mostly-VarDCT image.

The features read like a superset. Up to 32 bits per channel, HDR with Rec. 2100 primaries and PQ or HLG, alpha, animation, and genuine progressive decoding — a JPEG XL file can render a low-resolution preview from the first chunk of bytes and sharpen as more arrives, the behavior the web lost when it moved past progressive JPEG.

The headline trick is lossless JPEG transcoding. Because VarDCT can hold ordinary 8×8 DCT coefficients, JPEG XL can re-encode an existing JPEG by repacking its coefficients with a better entropy coder, typically shrinking the file by around 20 percent, and the process is reversible — you can reconstruct the original JPEG bit for bit. For the trillions of legacy JPEGs already in storage, that is a real argument: a smaller file that is not a new, lossy generation of the old one. This is the property that later pulled the PDF world toward the format.

On quality-per-byte the two are competitive rather than separated by some decisive margin. Results swing with the encoder, the settings, and the image. JPEG XL’s distinguishing advantages are less about average bytes saved and more about edges: high bit-depth work, the lossless transcode, and progressive rendering.

Why one stalled

If the formats are close, why is one nearly universal and the other not? The decisive events were political and happened in browser issue trackers, not in the codecs.

Google had AVIF support in Chrome by 2020. JPEG XL was added behind an experimental flag in 2021. Then, in late 2022, the Chrome team announced it would remove the JPEG XL code and flag entirely, landing the removal in Chrome 110 in early 2023. The stated reasons, posted to the Chromium tracker, were four: experimental flags should not live indefinitely; there was not enough interest from the whole ecosystem; the format did not bring sufficient incremental benefit over existing formats to justify enabling it by default; and removing it cut maintenance burden. Phrased that way it sounds procedural.

It did not land as procedural. The removal bug drew over a thousand upvotes and a long objection thread, an unusually loud response for a format flag. Adobe, Facebook, Intel, and Shopify were among the parties who had voiced support, which made “not enough interest” a contestable claim rather than a settled one. The Free Software Foundation weighed in, framing the decision as an argument for browser choice and for unencumbered formats. And Jon Sneyers, one of JPEG XL’s designers, suggested publicly that the call reflected an internal tension at Google between the JPEG XL camp and the teams behind Google’s own AVIF and WebP. That last point is an allegation, not an established fact, and Google’s engineers have framed the decision in the narrower maintenance terms above — but it is part of the record of how the episode was received, and worth reporting as a claim rather than a conclusion.

The mechanics underneath are worth stating plainly, because they are the actual lever. Browser engines are a near-duopoly. A format that Chromium declines is a format most of the web cannot rely on, regardless of merit, because the support number never crosses the line where a developer can ship it without a fallback. AVIF cleared that bar; JPEG XL did not, and so it lived on as a thing you could enable but not deploy. Merit set the ceiling. Distribution set the floor, and the floor is what shipping depends on.

What makes the story more interesting than a clean burial is that it has partly reversed. Apple shipped JPEG XL, enabled by default, in Safari 17 in 2023, which is why the format’s support figure is not zero. Mozilla, long neutral and openly worried about the security surface of the large C++ reference decoder, shifted once a memory-safe Rust decoder — jxl-rs — became the path forward. In late 2025 the PDF Association picked JPEG XL as its preferred format for HDR images, citing exactly the high-bit-depth and lossless-transcode properties above. And in that same window the Chromium team reopened the question and began integrating the Rust decoder, reversing the “obsolete” framing it had used to justify the removal three years earlier — though, as of this writing, the support is landing disabled by default while a long-term maintenance commitment is worked out.

So the honest summary is not “AVIF won and JPEG XL lost.” It is that AVIF won the distribution race cleanly and early, JPEG XL lost it on a contested call and spent three years as a format with admirers and no reach, and the case has since been quietly reopened from several directions at once. The codecs were never the bottleneck. For anyone shipping images today the practical advice is unchanged — reach for AVIF, keep a JPEG or WebP fallback — but the longer-run lesson is the duller and more durable one: a format’s fate is decided less by how it compresses than by who agrees to decode it.