Written on 8 October 2026.
On 6 October 2026 Google announced that "Chrome is shipping decoding support for the JPEG XL (.jxl) image format starting from Chrome 155." For a format many developers had stopped planning around, that is real news. It is also narrower than the headline suggests — and the gap between the two is where a site owner can spend money for nothing.
This is the sober version: what actually shipped, where it works, what Google's announcement does not say, and how to decide whether your site should do anything about it yet.
What shipped
Chrome can now decode JPEG XL — read a .jxl file and display it. That is what browsers do with images, so for a website it is the part that matters. It does not change how the files get made: producing .jxl images is still the job of your build pipeline, your image CDN or whoever exports your photography.
Google also explains how it built the decoder. Chrome uses jxl-rs, "a pure Rust implementation of the JPEG XL decoder," because, in the post's words, "Image decoders are one of the most critical and targeted attack surfaces in any modern web browser." A new image format is new code parsing untrusted files from the network, so a memory-safe decoder is the right way to add one.
Where it now works
Chrome joins Safari. WebKit's release notes for Safari 17.0, published on 18 September 2023, state plainly: "Safari 17.0 adds support for JPEG XL." So .jxl is no longer a one-browser format.
That is still not "everywhere". We have not checked every other browser, and Google's post does not list them, so don't assume one way or the other — check the browsers your own visitors use in your analytics.
What the announcement does not say
Whether it is on by default. The post says Chrome is "shipping" support "starting from Chrome 155", but it does not say whether the feature is switched on for every user of that version. Chrome's own feature tracker still listed it as "Proposed" when we looked on 8 October. Until that is settled, don't build anything that assumes every Chrome 155 visitor can display a .jxl.
Who has Chrome 155 yet. Chrome 155 reached the stable channel on 6 October 2026, according to Chromium's release schedule. Browsers update gradually: on 8 October the copy of Chrome on our own machine was still on version 154. "Shipping in 155" and "your visitors have 155" are two different dates.
What Google says it is good for
The post claims JPEG XL "offers 30-50% better compression than JPEG". Read that carefully. It is Google's figure, and it is measured against JPEG — not against the AVIF or WebP that many sites already serve. It is not our measurement, and it tells you nothing about how much you would save over whatever your site uses today.
Google is also more measured than its headline number. Its advice is: "In general, we recommend trying both AVIF and JPEG XL to get the best results." And it says where it expects JPEG XL to help most: "for high-fidelity or lossless compression, especially of photographic images or in cases in which fine-grained progressive decoding is preferred."
That is a useful filter. If your site is mostly logos, icons and interface graphics, this is unlikely to be your next win. If it is heavy on high-quality photography — product shots, property listings, portfolios, galleries — it is worth a test.
How to adopt it without breaking anything
Never replace your existing images with .jxl. Add it in front of them, and let each browser take the first format it can use:
<picture>
<source srcset="photo.jxl" type="image/jxl">
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="…" width="1200" height="800">
</picture>The type attribute is what makes this safe: a browser that does not recognise image/jxl skips that line and moves on to the next one. The <img> at the bottom is the fallback every browser understands, and it carries your alt text and dimensions.
The cost is not in the HTML. It is in producing and storing another version of every image, and in making sure your image CDN, if you use one, can generate or serve .jxl at all. Check that before you plan anything around it.
Should you do anything yet?
- Mostly graphics, or already serving AVIF/WebP well? Probably not yet. Wait until the default question is settled and Chrome 155 is widespread.
- Photography-heavy site still serving only JPEG? Fix that first with AVIF or WebP, which work today, then consider adding JPEG XL in front.
- Photography is the product? Test it. Encode a representative sample of your own images in JPEG XL and in the format you already use, at the same visual quality, and compare. Your images are the only benchmark that answers the question for your site.
In every case: keep your original high-quality files. A format decision is easy to reverse if you still have the originals, and very hard if you don't.
Want to know if it is worth it for your site?
If you would like a straight answer for your own images rather than a general one, get in touch. We can test a sample of your images against the formats you already serve, and tell you whether adding JPEG XL is worth the extra work.
Sources
- Google, "Shipping JPEG XL in Chrome" — developer.chrome.com/blog/jpeg-xl-in-chrome, published 6 October 2026 (read 8 October 2026)
- WebKit, "WebKit Features in Safari 17.0" — webkit.org, published 18 September 2023 (read 8 October 2026)
- Chromium release schedule (Chrome 155 stable date) and Chrome Platform Status feature entry (read 8 October 2026)