JPEG XL critique says AVIF now beats it on compression

Gianni Rosato published a detailed technical case against JPEG XL on September 13, 2026. He argues that current AVIF encoders now beat JPEG XL across the whole quality range. The timing matters for anyone shipping images on the web, because Firefox 157 is due to turn JPEG XL on by default at the end of September.

JPEG XL is an image format standardized in 2022 as ISO/IEC 18181. AVIF is the rival format built from the AV1 video codec. Both aim to produce smaller files than JPEG at the same visible quality.

One thing to know before the numbers: Rosato works on the competing format. He writes that he does image compression work, and that "while working on an AV1 encoder, Julio Barba and I made significant advancements to AVIF." He discloses this in the post itself. It does not make his measurements wrong. It does mean no independent party has checked them yet.

What the post claims

Rosato starts by granting the format its due. "JPEG XL is a technically impressive image codec; it is a definitive upgrade over JPEG," he writes. His case is against JPEG XL compared with AVIF, not compared with JPEG.

On lossless compression he measures JPEG XL at about 11.9% smaller than lossless WebP on realistic web content. He treats that as a small return for the work the format demands. On lossy compression he reports that current AVIF encoders score better on three perceptual metrics: CVVDP, MS-SSIM and SSIMULACRA2. Those metrics estimate how similar two pictures look to a person, instead of just counting changed pixels. "AVIF now dominates the entire fidelity range," he writes.

He also names compression tools JPEG XL does not have. It has no directional prediction modes and no deblocking loop filter. Directional prediction lets an encoder predict a block of pixels from its neighbors along an angle, which helps on hard edges. A deblocking filter smooths the visible seams between compressed blocks. He argues that missing both limits the format on non-photographic images, such as screenshots and line art.

The decode bomb

The sharpest claim is about decode time rather than file size. Rosato describes a deliberately built image he calls the prime wall. It is 1,918 bytes, and it took 17.43 seconds of user time to decode on an M5 Pro. He writes that "the prime wall image is just 1,918 bytes, so it's about to become trivially easy to JXL-bomb low-end devices."

That is a denial-of-service shape, not a quality complaint. A two-kilobyte upload that costs seconds of CPU is a problem for any service that decodes images users send it. He attributes the opening to how expressive the JPEG XL specification is. Some constructions are legal and also extremely slow.

He reports two further decode findings. WebP decodes more than 10 times faster than JPEG XL in his tests. Progressive rendering also works in AVIF now, and that had been one of JPEG XL's clearest remaining advantages.

The two sides measure different baselines

The JPEG XL project's own work complicates the speed picture. jxl-rs is the Rust decoder that the project says ships in both Chrome and Firefox. Its repository describes the goal as full conformance with the specification, with better memory safety and decoding performance than libjxl, the official C++ reference software. The project says jxl-rs closely matches and sometimes exceeds that reference, with lower memory use.

Those claims and Rosato's do not collide directly. He measures JPEG XL against WebP and AVIF. The project measures its new Rust decoder against its own older C++ one. A decoder can beat its predecessor and still lose to WebP. Read together, the two describe real progress on decode speed that has not yet closed the gap Rosato reports.

What this means for developers

Do not change formats because of one post. Every figure above comes from one author's test set, and that author works on the format that wins his comparison. The right response is to measure your own images, because compression results swing hard with the content.

Three things are worth doing this month. First, encode a real sample of your production images as both AVIF and JPEG XL, and record the sizes at a quality you would actually ship. Second, time the decodes on a cheap phone rather than on your laptop. Third, if you accept image uploads, put a hard time and memory limit on decoding, then test it with a deliberately awkward file.

That third item earns its place whether or not you ever ship JPEG XL. The prime wall is a JPEG XL example, but every modern codec has pathological inputs. An upload path with no decode budget is the actual bug.

For most sites the practical advice has not moved much since Mozilla's shipping announcement. Use AVIF for ordinary photographs, and JPEG XL where progressive rendering of very large images matters. What this critique adds is a reason to re-test that second case, because AVIF's progressive support is no longer the weak point it was.