JPEG XL in Chrome 155, Measured: 21% Off Existing JPEGs With a Byte-Exact Way Back

Measured with libjxl 0.11.1, libavif 1.3.0, libwebp 1.6.0 and libjpeg-turbo 3.1.3 on 2026-10-11.

On 6 October the Chrome team announced that Chrome is "shipping decoding support for the JPEG XL (.jxl) image format starting from Chrome 155", using a decoder written in Rust.¹ The post gives one compression figure, "30-50% better compression than JPEG", and one piece of advice: try both AVIF and JPEG XL.¹

We ran the encoders to see what a site would get.

• Lossy, at matched quality, JPEG XL was 22.5% and 23.2% smaller than JPEG at two quality levels on a standard 24-image set. Four of the 24 images reached the 30% the announcement starts at.
• AVIF was within three points of it both times, and won on half the images at the lower quality level.
• Recompressing existing JPEGs without touching a pixel saved 20.8% across 30 real photographs, and every one of the 30 converted back to a file identical to the original, byte for byte.

The third result is the one with no equivalent in WebP or AVIF, and it is the one the announcement mentions without a number.

Recompressing the JPEGs you already have

Every other modern format asks you to decode a JPEG to pixels and encode again, which adds a second generation of loss on top of the first. JPEG XL has a separate mode for JPEG input that repacks the existing image data instead of re-encoding pixels. In the reference tools that mode is the default. cjxl photo.jpg photo.jxl applies lossless recompression, and djxl photo.jxl photo.jpg reconstructs the original file.²

We tested it on 30 photographs from Wikimedia Commons' featured pictures: sampled evenly from the 146 JPEGs between 1.5 and 9 MB among the 500 most recently added, 544 megapixels in total.³ These are camera and stitched-panorama files as their authors exported them, which is what an upload folder looks like.

jpegtran is in the table because it is the lossless optimisation most pipelines already have. JPEG XL saved three times as much. The spread is narrow: 21 of the 30 files landed between 14% and 22%, so a fifth is a fair planning number for photographs.

Then the round trip. We converted each .jxl back to .jpg and compared it with the original using cmp. All 30 were identical, metadata included. Encoding the whole set took 11.3 seconds and reconstructing it took 5.6, on a laptop.

That changes what "adopting a format" has to mean. You can store the JPEG XL file as the only copy, serve it to browsers that decode it, and reconstruct the exact original JPEG for everything else. Nothing is lost if the format's fortunes change again, because the way back is exact. The cost is CPU on the fallback path, about 0.2 seconds per image at these sizes, which you would cache.

Lossy: about a quarter, and level with AVIF

For new encodes we used the Kodak set, 24 lossless 768x512 photographs and a long-standing reference set for this kind of comparison.⁴ Comparing formats at "quality 80" is meaningless, because each encoder's scale means something different, so for each image and each format we searched for the lowest quality setting whose output reached a target score on SSIMULACRA2, a perceptual metric, and recorded the file size at that setting.⁵ Two targets: 80, which the metric's authors describe as "very high quality", and 60, which sits between their "medium" and "high".⁵

The JPEG baseline is libjpeg-turbo with optimised Huffman tables and progressive encoding, which is what a careful pipeline produces. WebP is cwebp -m 6, AVIF is avifenc -s 6, JPEG XL is cjxl -e 7, all close to defaults.

The total hides a wide range. At target 80, JPEG XL's saving per image ran from 12.8% to 40.7% with a median of 23.7%. Four images out of 24 saved 30% or more, and nine saved less than 20%. At target 60 seven images cleared 30%. So "30-50%" describes the best few images in this set. It is a result you can get on an image, and it is not what the set averaged.

Two things could move that number, in opposite directions. Against a plain baseline JPEG with no optimisation, the gap would be wider. Against mozjpeg, it would be narrower. And the metric itself is not neutral ground: SSIMULACRA2 was developed by one of JPEG XL's authors and ships with libjxl.⁵ If it leans anywhere, it leans toward the format that came in under the claim.

Against AVIF the answer is a tie. JPEG XL produced the smaller file on 16 of 24 images at the higher target and on 12 of 24 at the lower one, and the totals differ by 3% and 0.5%. That is the Chrome post's own position, that the two are worth trying side by side, with JPEG XL expected to do best at high fidelity and lossless.¹ Our numbers agree with the direction: its lead over AVIF is larger at 80 than at 60.

WebP is the format this result should worry. At matched quality it saved 12 to 15%, about half of what either newer format did.

Lossless: where it leads clearly

The same 24 images, encoded losslessly from the PNG files as distributed:

All 24 JPEG XL files decoded to pixels identical to the source. The PNGs were not run through an optimiser first, so part of every row is PNG slack. The order between the three formats does not depend on that.

Who can decode it

Support is the reason this format spent years as a curiosity, so it is worth being exact. The compatibility data lists Chrome as supporting JPEG XL from 155, with the format behind a flag in 145 to 154; before that it was behind a flag in 91 to 109 and absent from 110 to 144.⁶ Safari has had it since 17.0, marked partial.⁶ The same table puts global coverage at about 17% today, a figure that will follow Chrome's rollout.⁶

That means a fallback is not optional yet. The <picture> element handles it without scripting, because a browser skips any <source> whose type it does not support:⁷

<picture>
  <source srcset="photo.jxl" type="image/jxl" />
  <source srcset="photo.avif" type="image/avif" />
  <img src="photo.jpg" alt="..." width="1200" height="800" />
</picture>

For images served from one URL, content negotiation on the Accept header is the other route. Confirm that the browsers you care about send image/jxl there before relying on it.

What to do with this

1. Start with the archive, not the pipeline. If you store large numbers of user-uploaded or legacy JPEGs, lossless recompression is a fifth off storage with no quality decision to make and no risk to the originals. It does not need any browser to support anything.
2. Do not replace a working AVIF setup for bytes. At matched quality the two were level. Add JPEG XL where it measurably wins for you, which on this evidence is high-quality photographs and lossless images.
3. Reconsider WebP as the default "modern" format. It was the weakest of the three by a wide margin here.
4. Budget for a quarter when estimating what moving off JPEG saves. Measure your own images before quoting a number to anyone.
5. Keep the fallback until the coverage figure is one you would accept for any other feature.

Where this is weak

• One metric. Matching on SSIMULACRA2 is a choice. A different metric, or human viewers, could reorder AVIF and JPEG XL, which are close enough for that to happen.
• Small, old test images. The Kodak set is 24 film photographs at 768x512. It has no screenshots, no illustrations, no text, and nothing at the resolution a phone produces. Results on interface graphics may look nothing like these.
• No browser decode test. The machine these ran on has Chrome 154, where the format is still behind a flag, so we measured encoders and the reference decoder, not Chrome's. Decode speed and progressive rendering in the browser are untested here.
• Encoder settings near defaults. Slower settings improve every format, and not equally.
• One sample of 30 for recompression, all photographs. Files that are already heavily optimised, or very small, will save less.
• libjxl 0.11.1, the version packaged for this system, where 0.12.0 is current.

FAQ

Does Chrome support JPEG XL?

Yes, from Chrome 155, announced on 6 October 2026. Decoding uses jxl-rs, a Rust implementation.¹ Earlier versions had it behind a flag or not at all.⁶

How much smaller is JPEG XL than JPEG?

At matched perceptual quality on the Kodak set, 22.5% to 23.2% in our runs, with individual images between 9% and 45%. The Chrome post says 30-50%;¹ between a sixth and a third of our test images reached that range, depending on the quality level.

Can JPEG XL convert a JPEG without losing quality?

Yes. The reference encoder recompresses JPEG input losslessly by default, and the decoder can reconstruct the original file.² On 30 photographs we measured a 20.8% saving and 30 byte-identical round trips.

Is JPEG XL better than AVIF?

For lossy photographs at the quality levels we tested, they were level: JPEG XL was smaller on 16 of 24 images at high quality and 12 of 24 at medium. For lossless images JPEG XL was clearly smaller, 33% under PNG against AVIF's 11%.

Should I serve JPEG XL now?

With a fallback, yes. Use <picture> with type="image/jxl" and keep AVIF, WebP or JPEG behind it.⁷

Sources

Checked 2026-10-11.