A Compression Engineer Said JPEG XL Should Not Ship, Three Weeks After Firefox Shipped It
The case against JPEG XL pulled 201 points and 269 comments on Hacker News and 22 points on Lobsters. We ran the codecs ourselves to see which side the numbers actually support.
The WJS Desk
Sep 14, 2026 · 7 min read
On 13 September, Gianni Rosato published "The case against JPEG XL", arguing that the format should not have been added to the web platform because AVIF already does the job. By the next morning it had 201 points and 269 comments on Hacker News.
On Lobsters the same article got 22 points and 9 comments. Three weeks earlier, Mozilla's "Intent to Ship: JPEG XL" had pulled 109 points and 18 comments on that same site. Same format, same community, one fifth the interest in the argument against it.
That gap is the story, so we read both threads end to end and then did the thing neither thread did, which is run the codecs.
The argument, stated fairly
Rosato is a compression engineer who has worked on SVT-AV1, and he identified himself as the post's author in the Hacker News thread under the handle computerbuster. His case is narrower than the headline suggests, and it is worth stating at full strength.
He argues that on the web specifically, lossless barely matters (he puts JPEG XL's lossless edge over WebP at 11.9%), that JPEG XL's lossy mode trails AVIF on CVVDP, MS-SSIM and SSIMULACRA2, that it lacks directional prediction and a proper deblocking loop filter, and that it decodes slowly enough to be a denial of service risk. His example is a 1,918-byte file that took 17.43 seconds of CPU to decode. His conclusion is that browsers should ship codecs that are "purpose-built, efficient, and narrowly scoped", and that JPEG XL is the opposite of that.
The counter-argument, at its strongest, was put by kangalio on Lobsters:
In my opinion, the case for JPEG XL is not its depth, it's its breadth. [...] It's the format you choose as default for anything where spending dozens of hours measuring the perfect codec is overkill, and you just want a kick-ass generalist codec that's ready for everything you throw at it in the future.
Nobody on that side is claiming JPEG XL beats AVIF at shipping photos to a browser. They are claiming that optimising for that one case is how you end up juggling four formats.
We ran the claim everyone repeats
The single most-cited argument for JPEG XL in both threads is lossless JPEG recompression: you can shrink an existing JPEG and get the original bytes back. twotwotwo on Lobsters put it at "~22% smaller with no added loss". dimatura on Hacker News said "something like 15-20%".
We had cjxl and djxl 0.11.2 and libavif 1.3.0 installed, so we tested it on three Pexels photographs at 1920px wide, transcoding with cjxl --lossless_jpeg=1 and decoding straight back with djxl.
| Source JPEG | As JXL | Saved | Round trip |
|---|---|---|---|
| 156,343 B | 125,585 B | 19.7% | Byte identical |
| 535,896 B | 460,600 B | 14.1% | Byte identical |
| 136,311 B | 109,289 B | 19.8% | Byte identical |
The feature is real and it works exactly as advertised. cmp reported no difference on all three round trips. But 14.1% to 19.8% is not 22%, and the one image where the saving was weakest was the largest and most detailed of the three. If you are sizing a CDN migration off the number people quote in threads, budget lower.
And the claim nobody wanted to test
Decode speed is where the article is hardest on JPEG XL. We could not reproduce its specific comparison, because it benchmarks jxl-rs against WebP and we were running the C++ libjxl against libavif. So this is a different measurement, not a check of his.
We encoded each image with cjxl -d 1, then searched AVIF quality settings until the output landed within 4% of the JXL file size, and decoded both to PPM five times, taking the fastest run.
| Image | Threads | djxl | avifdec | Ratio |
|---|---|---|---|---|
| 1920x1440 skeleton | all | 45 ms | 26 ms | 1.73x |
| 1920x1440 payphones | all | 47 ms | 25 ms | 1.87x |
| 1920x1280 classroom | all | 42 ms | 24 ms | 1.73x |
| 1920x1440 skeleton | 1 | 76 ms | 27 ms | 2.82x |
| 1920x1440 payphones | 1 | 76 ms | 24 ms | 3.19x |
| 1920x1280 classroom | 1 | 72 ms | 25 ms | 2.89x |
AVIF was also 2.4% to 4.0% smaller at that setting. So the direction of Rosato's argument holds up on our machine: at matched size, JPEG XL costs you decode time, and single-threaded (which is the case that matters on a phone) it costs about three times as much.
Read these numbers narrowly. Three images is not a codec study. Our sources were already-compressed JPEGs, our timings include process startup and writing an 8 MB PPM, and we ran on Apple Silicon. The ratios are a floor, the absolute milliseconds are not meaningful, and a real comparison needs SSIMULACRA2 scoring we did not do.
What the platforms disagreed about
Hacker News argued about whether the article was correct. Lobsters argued about whether the question was the right one.
On Hacker News the thread turned into a technical scrap over progressive rendering, and the people who build AV1 showed up. aniviacat claimed AVIF's progressive support is "false advertising" and really just a layered thumbnail. Three separate people corrected them, including derf_, who noted in-thread that he leads Mozilla's technical contributions to AV1:
Unlike a thumbnail, higher-resolution layers can be predicted from the lower-resolution layer, so those bits are not wasted. That is not possible by layering <img> elements.
Even the correction got qualified. nneonneo loaded the demo and reported that the JXL "continues to refine during most of the download [...] I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec."
On Lobsters almost nobody disputed the benchmarks. They disputed the framing. david_chisnall went straight at the premise that the average web user is the relevant unit:
A use case that affects 1% of web users is a requirement for more people than live in most European countries. The scale of the web means that appeals to averages are highly misleading.
And DustyFuzzy gave the cleanest version of why the Lobsters crowd is unmoved: "I don't need another image format designed for the web, I need an image format that happens to work on the web. Until JXL, that was either JPEG, or PNG."
The split is not really about compression. Hacker News weighed a codec for a delivery pipeline. Lobsters weighed a codec for a filesystem. Those are different jobs and the same benchmark cannot settle both.
The best comment nobody upvoted
Sitting at one point on Lobsters, paulirish left a single line:
Something to keep in mind.. the SSIMULACRA 2 metric designer is the same as the author of JXL. (Not problematic, just an FYI..)
This is load bearing and almost everyone scrolled past it. One of the three metrics the article uses to show JPEG XL losing was designed by one of JPEG XL's own authors. That makes the result stronger, not weaker: the format underperforms on a yardstick built by its own side.
Except pekkavaa had already complicated it on the other Lobsters thread: "SSIMULACRA2 penalizes any kind of block artifacts heavily and prefers blurrier results." If that is right, the metric systematically favours AVIF's failure mode over JPEG XL's, and several people in both threads independently said JXL simply looks better to them at high quality. Levitating reported doing "extensive testing" on their own photographs and preferring JXL on both quality and size.
Nobody resolved this. A methodological objection that could flip the article's central chart got one upvote, which is how threads work.
Our read
On the narrow question, Rosato wins. For delivering lossy photographs to a browser, our own numbers agree with his direction: AVIF was smaller and decoded faster in every pairing we ran. If that is your entire problem, you do not need JPEG XL.
But the sharpest reply in either thread came from ignaloidas on Lobsters, at two points, and it is hard to unsee:
"I have worked for 3 years on AVIF encoders while almost no work was done on JPEG XL encoders, and so AVIF is now better and it's time to ignore JPEG XL" is certainly a take.
That is not an answer to the benchmarks. It is a question about what they measure. Encoder maturity is not a property of a format, and the comparison is between a codec that got years of funded encoder work and one that got very little because browsers would not ship it.
It is also late. Firefox already shipped, on the Rust jxl-rs decoder Mozilla asked for specifically because 100,000 lines of multithreaded C++ was too much attack surface. Safari shipped in 2023. And as pilif pointed out on Lobsters, Adobe put JPEG XL in the PDF spec, so every browser that renders PDFs needs the decoder regardless of what it does for <img>. The decoder is going in the binary either way. That, not the SSIMULACRA2 charts, is why this argument was over before it started.
What would change our mind: a funded year of libjxl encoder work that closes the lossy gap, or a reproducible in-browser decode benchmark on mobile hardware showing the DoS risk is real in practice rather than in a crafted 2 KB file.
Your turn
If you have actually shipped one of these to production: what did your transfer bytes do, and did anyone notice the quality change? The thread is full of people comparing crops at 400% zoom and almost empty of people reporting what happened to a real page weight. That second number is the one that settles it.
If you want to see how we run this kind of check, our bzip3 piece is the same exercise on a compressor rather than a codec: we reproduced the headline win, and then found what the release notes had left out.
