Chrome 155 Ships JPEG XL: We Ran It on Our Own 162 MB Image Library
Chrome 155 went stable on October 6-7, 2026 with JPEG XL decoding on by default, and Firefox slipped from 157 to 158 (October 13). Instead of writing another take, we transcoded 40 real JPEGs from our own site with cjxl: -22.9% at zero quality loss, verified bit-for-bit. The bigger finding: 34 of our 598 .jpg files were never JPEGs at all.
Chrome 155 Ships JPEG XL: We Ran It on Our Own 162 MB Image Library
Chrome 155 went stable on October 6-7, 2026 with JPEG XL decoding enabled by default on Windows, Linux, macOS and Android, and Firefox corrected its date: no longer 157, but 158, on October 13. Safari has supported it since 2023. In other words, within four days the format stopped being a bet and landed in almost everyone's browser. Rather than write another take on it, we did the one thing a generative model cannot produce: we transcoded our own files. Across 40 real JPEGs from our site, lossless conversion to JPEG XL removed 22.9% of the bytes without touching a single pixel, with the copy verified bit for bit in 15 of 15 tests. And on the way we found a problem considerably worse than any format war: 34 of our 598 .jpg files were never JPEGs at all.
What changed this week — and where we were wrong in September
On September 2 we published our JPEG XL forecast: Firefox 157 would enable the format by the end of the month, Chrome had formalized its intent, and "before the end of 2026" it would be in all three engines. Almost every important detail came out backwards:
- Chrome went first. Google announced Shipping JPEG XL in Chrome on October 6 and rollout began on the 7th: Chrome 155 decodes
.jxlby default, no flag. The decoder is no longer libjxl's C++ but jxl-rs, a Rust reimplementation that reaches SIMD through the stabilizedtarget_feature_11and that, according to the team, has never had a memory-safety bug in its entire history. - Firefox slipped. Default activation moved from 157 to 158, October 13, and that release also adds
image/jxlto the image Accept header (MDN merged it on October 8). That detail matters: without that header, Accept-based negotiation cannot work in Firefox. - The cadence is bi-weekly now. Chrome and Firefox moved to two-week releases in September; timelines everyone projects in quarters now move in days.
The lesson is ours, not the ecosystem's: predicting the order of launches is easy, predicting the calendar is not. What we did get right was the measurable part.
What we measured, exactly
We audited the site's image folder: 598 files with a .jpg or .jpeg extension, 162.6 MB in total. Of those, 564 are real JPEGs (117.1 MB). From those we took a fixed random sample of 40 (seed 20261009, 8.1 MB) and ran libjxl 0.7.0's cjxl plus ffmpeg for the comparisons:
- Lossless JPEG XL:
cjxl in.jpg out.jxl— no flags, because as the encoder itself warned us ("Implicit-default for JPEG is lossless-transcoding"), JPEG input already defaults to lossless transcoding. - Lossy JPEG XL:
--lossless_jpeg=0at distance 1 and distance 4. - WebP q80 and AVIF crf 30 as references.
- Verification:
djxlrestored the JPEG and we compared MD5 against the original file.
Results: lossless wins on risk, AVIF wins on bytes
| Format and setting | Total (40 files, 8.1 MB) | Median per image | Median encode |
|---|---|---|---|
| Original JPEG | 8,136,406 B (base) | — | — |
| Lossless JPEG XL | 6,273,605 B (-22.9%) | -23.1% (-14.0% to -34.7%) | 0.09 s |
Lossy JPEG XL -d 1 | 3,962,485 B (-51.3%) | -51.8% | 0.46 s |
Lossy JPEG XL -d 4 | 1,724,679 B (-78.8%) | -78.9% | 0.50 s |
| WebP q80 | 2,403,384 B (-70.5%) | -70.0% | ~0.27 s |
| AVIF crf 30 | 1,450,919 B (-82.2%) | -82.2% | ~0.72 s |
Three conclusions that matter more to us than the percentage:
- Our September estimate (~20% at zero quality loss) held up: -22.9% on average, -23.1% median, and in 15 of 15 files the restoration was bit-for-bit identical to the original. It is the only move in the table that requires negotiating quality with nobody.
- Lossless encoding is nearly free: 0.09 s per image versus ~0.72 s for AVIF in our runs. Generating a JPEG XL layer in the build does not move the deployment needle — an argument we already made in the AVIF vs WebP guide for Astro.
- On raw bytes, AVIF still rules: -82.2% versus -51.3% for lossy JPEG XL at distance 1 (and this is not a like-for-like comparison: settings were fixed, not perceptually matched). Claiming that JPEG XL "beats AVIF" with these numbers would be lying with the table in front of you.
The finding that beats any format
Auditing the files turned up something no format article will tell you: 34 of our 598 .jpg files (5.7%) contain PNG, and those 34 files weigh 45.5 MB — 28% of every image byte on the site. The largest real JPEG in the library weighs 715 KB; our heaviest files are exactly those PNGs wearing a JPEG extension.
Verified live against the CDN: content-type: image/jpeg, content-length: 1921827 and, to top it off, x-content-type-options: nosniff, for a file that is a 1536×864 PNG inside. The browser paints it anyway, but anything that trusts the header — Accept negotiation, CDN transformers, tools that re-encode assuming JPEG — is being fed a lie.
The cause sits in our own house and is instructive: our publish-draft.py already has a guard that detects PNG bytes and converts them with ffmpeg -q:v 2 before saving them as .jpg. Well: 28 of the 34 files were committed AFTER that guard existed (June 3, 2026), and 9 of them in September alone. Something along that path fails silently — a conversion that returns an error and writes the original bytes anyway, or a download that skips the guard — and nobody was looking at it.
And here are the numbers that close the argument:
| What to do with those 34 files | Total weight | Change |
|---|---|---|
As they are today (PNG in .jpg) | 45,455,711 B | base |
| Re-encode to WebP q80 | 2,446,696 B | -94.6% |
| Re-encode to AVIF crf 30 | 2,470,640 B | -94.6% |
| Lossless JPEG XL | 28,733,738 B | -36.8% |
Scaled to the whole library: the lossless JPEG XL layer over the 564 real JPEGs would save roughly 27 MB (117.1 → ~90.3 MB). Fixing the 34 mislabeled files saves roughly 43 MB (45.5 → ~2.5 MB). Fixing the file format returns 1.6× the entire JPEG XL layer, and it takes one script, without touching a single URL and without waiting for any browser to update. (Before converting them in bulk we would visually review the text-heavy screenshots: -94.6% is a byte figure, not a quality verdict.)
What we're doing this week and what we're deferring
| Action | When | Why |
|---|---|---|
| Magic-byte check before every image commit | This week | It is the bug, not the format: 43 MB sitting there |
| Re-export or re-encode the 34 mislabeled PNGs | This week | 1.6× the savings of the entire JPEG XL layer |
| JPEG XL layer for heroes, product and galleries only | After October 13 (Firefox 158) | With image/jxl in Accept, negotiation works across all three engines |
| Replace AVIF with JPEG XL | No | Our numbers say the opposite: AVIF -82.2% vs -51.3% |
| Version decoders and audit transform code | Ongoing | Adding a format means adding code that processes untrusted bytes: the Next.js AVIF RCE taught us that expensively |
Our opinion, no hedging
JPEG XL is not going to win the byte war on a photographic catalog; AVIF is more aggressive and is already everywhere. JPEG XL wins something else: it is the only format with which you can compress what you have already published without losing a pixel and without renegotiating the design. That, plus progressive decoding — which on slow connections, the reality across much of Latin America, is felt more than the bytes — is an experience argument, not a benchmark one.
But execution order matters more than format: fix the file first, then the code, and only at the end the format. We had 45.5 MB of PNGs passing as JPEGs while we debated whether the JXL layer should come before or after AVIF in the <picture>. If your site has a performance budget to defend — ours is documented here — start by auditing what is inside your .jpg files. Surprises in that list usually cost more than any format discussion.
FAQ
Does Chrome support JPEG XL now? Yes: Chrome 155 (stable since October 6-7, 2026) decodes it by default on Windows, Linux, macOS and Android. Safari since 17.0 (2023). Firefox enables it in 158, on October 13, together with image/jxl in the Accept header.
How much does converting a JPEG to JPEG XL save? In our own real sample: -22.9% on average at zero quality loss, with output bit-for-bit identical to the original. That is a figure from our own library, not a vendor promise.
Should I replace AVIF with JPEG XL? No. AVIF removed the most bytes in our tests. JPEG XL serves a different purpose: recompressing what already exists without risk, with fast encoding and progressive decoding.
Frequently Asked Questions
Does Chrome support JPEG XL now?
Yes. Chrome 155 went stable on October 6-7, 2026 and decodes .jxl by default on Windows, Linux, macOS and Android, using the Rust decoder jxl-rs. Safari has shipped it since 17.0 (2023). Firefox turns it on by default in version 158, scheduled for October 13, 2026, after slipping from 157, and that release also adds image/jxl to the image Accept header.
How much smaller are JPEG XL files than JPEG?
On our own sample of 40 real JPEGs, lossless JPEG-to-JPEG-XL transcoding cut total weight by 22.9% (median -23.1% per image, range -14.0% to -34.7%) without touching a single pixel: djxl's output matched the original bit for bit in 15 of 15 files tested. Lossy encoding reaches -51.3% at distance 1 and -78.8% at distance 4, but those are no longer like-for-like comparisons.
Should I replace AVIF with JPEG XL?
No. In the same 40 images, AVIF at crf 30 removed the most bytes (-82.2%), ahead of WebP q80 (-70.5%) and lossy JPEG XL. JPEG XL's advantage is not winning the byte war: it is recompressing your existing JPEG archive with no loss, reversibly and at very fast encode speeds, plus progressive decoding that AVIF and WebP do not offer.
