JPEG XL vs JPEG

The short answer

For storing photos, JPEG XL wins on size in everything we measured; the price is speed. It can take a JPEG you already have and shrink it by around 20% with a guarantee that the original file can be rebuilt exactly, and when you compress a photo from scratch it needs far fewer bytes than JPEG for the same visual quality.

For sending photos to other people, JPEG is still the safe choice. Since October 2026 the three main browsers (Chrome, Firefox and Safari) display it by default, and Edge doesn't yet. That is a real change, but plenty of apps, upload forms and older devices have not caught up. JPEG opens everywhere; JPEG XL opens in more places every month.

The rest of this page is the evidence: two tests, the numbers for every photo, and exactly how we ran them, with links to every photo, so you can repeat it.

The catch: HDR gain maps and motion photos

Three of our phone photos carry something extra glued on after the end of the main image. The two Pixel 7 photos contain an Ultra HDR gain map, a second small image that tells HDR screens how to brighten the picture, and one of them also carries the short video of a Motion Photo. The iPhone 12 shot taken on iOS 26 carries Apple's own HDR gain map.

cjxl keeps all of that, which is why the round trip is still bit-exact, but it stores those extra bytes as they are: it can only re-pack the main JPEG. That is why the Pixel photo with a video inside saved just 11.1%. Measured on the main image alone, the same three photos shrank by 18.3% to 21.5%, in line with the others.

The classic JPEG optimiser does something worse. jpegtran appears to save 50.7% on that Pixel photo, but only because it silently throws away the gain map and the video while leaving the metadata that says they exist. If you run lossless optimisers over a phone library, check what they do with these extras first.

Test 2: the same visual quality, how many bytes?

Re-packing only helps with JPEGs you already have. The other question is what happens when you save a photo from scratch, for example after editing it. Comparing "quality 80" in one encoder with "quality 80" in another means nothing, because the scales are unrelated. So we matched quality with a perceptual metric instead.

We shrank each photo to 2048 pixels on the long side, which erases most traces of its original JPEG compression, and encoded it at many quality settings with four encoders: libjpeg-turbo with its default 4:2:0 colour subsampling, libjpeg-turbo with full 4:4:4 colour, Google's jpegli, and JPEG XL. Every result was decoded and scored against the reference with SSIMULACRA2, and for each photo we interpolated the file size each encoder needs to reach the same score.

On SSIMULACRA2's own scale, 70 means high quality, where artefacts are hard to notice without the original next to it; 80 means you cannot tell the two apart side by side at 100% zoom; 85 means you cannot tell them apart flipping between them; and 90 is visually lossless.

Sizes are the median across the 16 photos, scaled to a 2048 × 1536 picture (3.1 megapixels). "JPEG turbo" is libjpeg-turbo with its default 4:2:0 colour, plus -optimize -progressive. The percentage under JPEG XL is its median saving against jpegli, the better of the two JPEG encoders, worked out photo by photo. *Only 13 of the 16 photos reached 90 with libjpeg-turbo at all; more on that below.

JPEG XL produced the smaller file on every photo at every level: 80 comparisons out of 80 against jpegli and 77 out of 77 against libjpeg-turbo. Against libjpeg-turbo, the JPEG library most programs and operating systems use, the median saving was 28% to 33% depending on the level; at a score of 80 it ranged from 16% to 63% depending on the photo. Google's jpegli closes part of that gap, but at the levels in the table JPEG XL still needed 20% to 24% fewer bytes. That is a more modest number than some you will read online, and it is what our photos actually gave.

The biggest wins came on smooth, clean pictures: at a score of 80, the swans against a blue sky and the poppy against clouds needed less than half the bytes of libjpeg-turbo as JPEG XL, and about 40% fewer than jpegli. Dense, detailed scenes such as the spring with trees or the red car still came out 14% to 16% smaller than jpegli. JPEG has nowhere to hide on a flat sky: its 8×8 blocks show up as banding and blocking first.

There is also a ceiling. With its default 4:2:0 colour subsampling, libjpeg-turbo could not reach 90 on 3 of the 16 photos even at quality 100, because halving the colour resolution caps how faithful it can get. Switching it to full 4:4:4 colour fixes that, but costs more bytes at the usual levels: it needed more than the 4:2:0 version up to 80 and less from 85 upwards.

If you want the settings rather than the scores: reaching 80 took a median quality of 83 in libjpeg-turbo and in jpegli, and a distance of 1.6 in cjxl. Reaching 85 took quality 91 and distance 1.0, which is exactly cjxl's default for non-JPEG input. Visually lossless (90) took quality 97 in libjpeg-turbo and distance 0.5 in cjxl.

Compatibility in October 2026

This is the row that decides most real choices, and it has moved more in the last fortnight than in the previous three years.

The sources: Chrome's change is listed as enabled by default from version 155 on Chrome Platform Status, and Firefox announced it in its 158 release notes. If you want to know what your browser does right now, our JPEG XL browser test checks it in a second. And if a .jxl lands on a machine that can't open it, the viewer or a conversion back to JPG fixes it without installing anything.

How we measured

Machine: a shared Ubuntu 24.04 server with 6 virtual AMD EPYC cores. Times are processor time (user plus system) for each command, run single-threaded where the tool allows it, which makes them much less sensitive to other load on the server than wall-clock time. Treat them as ratios, not absolute figures.

Tools: libjxl 0.12.0 (cjxl, djxl, ssimulacra2), libjpeg-turbo 2.1.5 (cjpeg, djpeg, jpegtran), jpegli built from its GitHub repository at commit 031a007 (June 2026), and ImageMagick 6.9.12 for the resizing.

Test 1 commands: cjxl photo.jpg photo.jxl --num_threads=0, the same with -e 9, then djxl photo.jxl back.jpg and a SHA-256 comparison. For comparison, jpegtran -copy all -optimize and jpegtran -copy all -progressive.

Test 2 commands: references made with convert photo.jpg -auto-orient -resize 2048x2048 -strip. JPEG with cjpeg -quality Q -optimize -progressive (plus -sample 1x1 for 4:4:4) at qualities 20 to 100, jpegli with cjpegli -q Q at the same qualities, JPEG XL with cjxl -d D at distances 0.2 to 15. JPEGs decoded with djpeg, JPEG XL with djxl, all scored with ssimulacra2. Sizes at each target score are interpolated between the two nearest settings, photo by photo.

The 16 photos (Wikimedia Commons, all CC0), so you can repeat the test: river at blue hour, birds in foliage, cathedral, swans, poppy, frozen bubble, rural landscape, locomotive, ship, aquarium, shop front at night, spring and trees, red car, hazy landscape, train station, leaves.

Limits: 16 photos is a small sample, not a study, and the result would shift with a different set. SSIMULACRA2 was developed by the same people who built JPEG XL; it is widely used and correlates well with human ratings, but a second metric or a panel of viewers could rank things differently. Our references come from JPEGs, not from raw files. All the scripts, the per-setting results as CSV and the source and licence of every photo are kept with the measurements, and we will gladly share them.

Keep reading