Chrome Killed JPEG XL in 2022. Now It's Quietly Back, and Here's Why
In this article
Bottom line: Google removed JPEG XL from Chrome in 2022, saying there wasn't enough ecosystem interest. Chromium has since restored support using jxl-rs, a memory-safe Rust decoder.
It shipped behind a flag in Chrome 145 in February 2026.
One secondary report says Chrome 155 turns it on by default, but I couldn't find Google's own announcement, so check the release notes.
For site owners, that means JPEG XL is worth testing now, but it isn't yet something to ship alone.
I ran no benchmark for this piece. I had no 14-day spreadsheet, and I won't invent one.
What I did was trace the paper trail behind one of the web's strangest reversals, and it taught me something I didn't expect about how formats actually die and come back.
The short version is that a codec Google called a dead end is being rebuilt inside Google's own browser.
It was rebuilt in a different programming language, for a different reason than anyone first argued.
The Setup: A Format Everyone Wanted, Killed by the One Browser That Mattered
JPEG XL is an image format designed to replace JPEG, PNG and GIF with one file type. It does lossy and lossless compression, handles transparency and animation, and supports HDR and wide color.
Its party trick is converting an existing JPEG to JPEG XL and back with no pixel loss. The savings are commonly cited at around 20%. That is a big deal when the web serves billions of JPEGs.
In late 2022, Chrome's team announced it was pulling the experimental support. The stated reasons were a lack of ecosystem interest and no clear advantage over formats already shipping.
Support was removed in Chrome 110 in early 2023.
The community was furious, and the irony was thick. Google engineers in Zurich had co-developed the format.
The Rules of This Investigation
Since I can't run experiments on a browser's internal politics, I set myself some ground rules:
- Primary signals over hot takes. Browser release notes, Chromium code changes and the platform status page count most.
- Secondary reports flagged as secondary. If only one outlet says it, I'll say so.
- No guessing on dates. Where sources conflict, I'll show the conflict.
That last rule matters, because the coverage right now is messy.
Round 1: How a Dead Format Came Back
The reversal didn't start with a policy change. It started with a security argument.
Image decoders parse untrusted data from any website you visit.
That makes them a classic place for memory-safety bugs, and the original C++ reference library, libjxl, was a large attack surface to ship.
Chrome's team signaled that it would reconsider if the decoder were written in a memory-safe language.
The community answered with jxl-rs, a Rust decoder. It was reportedly vendored into Chromium around December 2025 and wired up in January 2026.
Phoronix reported that JPEG XL image support returned to the Chromium code, and shortly afterward noted that Chrome 145 shipped with JPEG XL support.
Here's the part I found interesting. Google didn't reverse itself by saying "we were wrong about demand." It reversed itself by changing the engineering risk.
Demand hadn't changed much, but the cost of saying yes had dropped.
This fits a pattern I keep running into. WhatsApp rewrote its media handler in Rust for much the same reason, because parsing hostile media files is where memory bugs hurt most.
Rust is making whole categories of "too risky to ship" into "fine, ship it."
Round 2: The Deep Dive Into What Actually Shipped
This is where I had to be most careful. The headlines say "JPEG XL is back in Chrome," which is true but incomplete.
Test 1: Is it on by default?
Here the sources disagree.
- Chrome 145 (February 2026): The decoder is present, but you had to turn on the `enable-jxl-image-format` flag. I'm confident about this one.
- Chrome 155: One report, from WindowsForum, says it's enabled by default. That report also says Chrome's release notes confirm the feature in Blink only.
- Other guides: Some of them, including one last verified in July 2026, say no browser enables it by default yet.
The newest report is the one saying it's on, and I couldn't find Google's own announcement backing it. I'd treat it as likely but unconfirmed.
Before you plan anything around it, check Chrome's release notes and the platform status page.
Test 2: What about everyone else?
Safari has supported JPEG XL since 2023. Firefox is murkier.
One source says the jxl-rs decoder landed in Nightly, another says Firefox 152 restored decoding, and the Chrome 155 report says Firefox support is delayed to version 158.
I can't tell you which is right. Firefox's status is a moving target, so check the current release notes.
Other Chromium browsers are another open question. Edge, Brave and Opera usually follow Chrome, but I wouldn't assume they match its schedule or default settings.
Test 3: The feature gap
"Supports JPEG XL" can mean many things. A decoder that handles the basics is not the same as one handling every feature in the spec: animation, HDR, wide gamut, progressive loading and so on.
Early coverage focused on the headline, and the fine print is where your real-world results will differ.
When you test, check images with transparency, high bit depth and animation, not just a plain photo.
The Results: What the Evidence Says
Here's my scorecard from the paper trail:
| Question | Answer | Confidence |
|---|---|---|
| Is JPEG XL back in Chromium? | Yes, using the Rust jxl-rs decoder | High |
| Did it ship in stable Chrome? | Yes, behind a flag in Chrome 145 | High |
| Is it on by default? | Reportedly in Chrome 155 | Medium: single secondary report |
| Does Firefox support it? | Unclear: conflicting sources | Low |
| Is it safe to serve JXL alone? | No | High |
The last row is the one that matters for anyone running a website. Even in the best case, you will have visitors on browsers or versions that can't decode it for a long time.
What This Means for You
Your move depends on who you are.
If you run a website or a content-heavy product: Don't swap formats yet. Use the `
That costs you extra storage and a slightly more complicated pipeline.
If you're a photographer or run a media-heavy workflow: The lossless JPEG recompression trick is the one to watch.
It lets you shrink an existing archive without re-encoding it, and you can convert back to the identical original file. Try it on a copy first and verify the round trip yourself.
If you're a developer building image tooling: The jxl-rs decoder is the news.
A production-grade Rust decoder lowers the barrier for every other project that wanted to add support but didn't want to depend on a large C++ library.
If you just browse the web: Nothing changes today. Pages won't suddenly look different. Over the next year or two, though, you may notice images loading a bit faster on sites that adopt it.
One caution about the "Core Web Vitals will improve" claims floating around. Smaller files can help load metrics, but they only matter if the format is actually served to your visitors.
Treat any promised speedup as something to measure on your own site, not something to bank on.
The Twist: The Format Didn't Change, the Risk Did
Here's what stuck with me. For three years, the debate was framed as quality: is JPEG XL better than AVIF, is it worth the complexity, is anyone asking for it?
The thing that broke the stalemate wasn't a better benchmark or a bigger petition. It was a safer implementation.
The format was always good enough to want, but nobody could justify shipping a risky decoder to billions of people.
That suggests a lot of "dead" technology isn't dead at all. It may just be waiting for the engineering cost to come down.
I'm curious what you've seen on your end. Have you tried serving JPEG XL on a real site, and did the savings hold up? Or do you think Chrome was right to wait?
