JPEG XL Is Back in Chrome — and Rust Is the Reason

In February 2023, Google removed JPEG XL from Chrome and said the format lacked “sufficient ecosystem interest”. It became one of the most-commented issues in Chromium’s history.

In February 2026, Chrome quietly put it back.

What Actually Shipped

Chrome 145 reached stable on 10 February 2026. Its release notes contain one line about JPEG XL:

Adds support for decoding JPEG XL (image/jxl) images in Blink using jxl-rs, a memory-safe pure Rust decoder.

Two things in that sentence matter more than the headline.

“Decoding”, not encoding. Chrome can display a JXL file. It cannot produce one. That is normal for image formats in browsers and is not a limitation anyone should be surprised by.

jxl-rs, not libjxl. This is the whole story, and most coverage has skipped past it.

The Rust Decoder Is the News

The 2023 removal was explained in terms of ecosystem interest. That was the public reason. The harder, quieter obstacle was that shipping JPEG XL meant putting libjxl — a large, complex C++ image decoder — directly into the renderer process, on the most exposed attack surface a browser has.

Image decoders are a historically rich source of memory-safety bugs. They parse untrusted bytes from arbitrary websites, at high speed, in a privileged context. Chromium has spent years reducing exactly this class of risk.

jxl-rs is the libjxl team’s reimplementation of the decoder in Rust: memory-safe by construction, no unsafe parsing of hostile input. Once that existed and matured, the strongest technical objection to shipping JPEG XL stopped applying.

This is the pattern worth internalising, because it will repeat. A format’s browser prospects can depend less on its compression numbers than on whether someone writes a memory-safe decoder for it. JPEG XL’s compression was never the problem. Its implementation language was.

What It Does Not Change

Here is where a lot of the coverage goes wrong. Search results are currently full of “Chrome ships JPEG XL” and confident predictions of a default-on date in the second half of 2026.

Be careful with both.

The flag is off by default. Chrome 145 gates JXL behind enable-jxl-image-format at runtime and enable_jxl_decoder at build time. A user has to go to chrome://flags and turn it on. Approximately nobody does that.

No default-on date has been announced. The “H2 2026” claim circulating across SEO blogs does not trace to a Chrome release note, a ChromeStatus entry, or a blink-dev intent. Treat it as speculation until it comes from one of those.

So for delivery purposes, the situation is unchanged:

Browser	Decoder present	Enabled by default
Safari 17+	Yes	Yes
Chrome 145+	Yes	No
Firefox 152+	Yes	No
Edge 145+	Yes	No

Firefox shipped its own decoder in version 152 (16 June 2026), also disabled, behind image.jxl.enabled. Mozilla’s public position moved from negative to neutral.

All three major engines now contain a JPEG XL decoder. Exactly one of them turns it on.

Do Not Touch Your Picture Element

Your fallback chain should not change:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" width="1200" height="800" alt="…">
</picture>

AVIF is supported by every major browser by default and is 40% to 60% smaller than JPEG at matched quality. It remains the correct primary format. Nothing about Chrome 145 changes that.

If you already serve JXL as a first <source> for Safari users, keep doing it. That was correct before and it is still correct:

<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" width="1200" height="800" alt="…">
</picture>

Browsers that do not understand a type skip that source. There is no risk in listing it, and no benefit in rushing to add it either — Safari’s share of your traffic is the entire upside today.

What It Does Change: Archiving

The genuine shift is in risk, not in delivery.

JPEG XL can losslessly transcode an existing JPEG. Not “re-encode at high quality” — the actual original JPEG bytes can be reconstructed exactly, while the stored file is about 20% smaller.

# Lossless, fully reversible
cjxl original.jpg archived.jxl --lossless_jpeg=1

# Reconstruct: byte-identical to original.jpg
djxl archived.jxl restored.jpg
sha256sum original.jpg restored.jpg    # same hash

For anyone sitting on a large JPEG library, that is a 20% storage reduction with no quality decision to make and no information lost.

The argument against doing it was always dependency risk: you would be committing an archive to a format that one browser vendor had publicly walked away from. That argument is now substantially weaker. A format with decoders in Blink, Gecko and WebKit, plus ISO standardisation since 2022, is not a plausible dead end.

If you evaluated JXL archival in 2024 and rejected it on ecosystem risk, that decision is worth revisiting. Not the delivery decision — the archival one.

What to Watch

The question has changed shape. It used to be “will Chromium ever implement JPEG XL”. Chrome 145 answered that. The question now is “when does the flag flip”, and these are the signals that would actually indicate it:

1. A blink-dev “Intent to Ship” for JPEG XL. This is the real signal, and it is public. Nothing else counts.
2. A ChromeStatus milestone change on feature 5114042131808256, from behind-a-flag to a shipping milestone.
3. Firefox enabling image.jxl.enabled. Both vendors appear to be waiting on production evidence, and to some extent on each other.
4. jxl-rs reaching decode-conformance parity with libjxl. A decoder that cannot handle every conformant file is not one you enable by default.

Until at least the first of those happens, treat JPEG XL as Safari-only and build accordingly.

The Broader Lesson

This is a useful correction to a common assumption about how formats win.

JPEG XL has been technically better than its competitors for years. It compresses better than AVIF on most content, encodes faster, decodes faster, supports higher bit depths, progressive rendering, and lossless JPEG transcoding that no other format offers. None of that was enough.

What moved it was a decoder rewrite in a memory-safe language, four years after the format was standardised.

Format adoption is not a meritocracy of compression ratios. It is a function of implementation risk, vendor incentives, and who is willing to maintain the code. Worth remembering the next time a benchmark chart is presented as though it settles the question.

The Practical Summary

Question	Answer
Can Chrome display JXL now?	Only if the user enables a flag
Should I change my <picture> chain?	No
Should I switch to JXL for delivery?	No. Use AVIF.
Should I reconsider JXL for archival?	Yes
Is a default-on date announced?	No. Ignore claims otherwise.
Is JXL a dead format?	No, and that is what changed

For the full format picture, see the JPEG XL adoption guide, which now reflects the Chrome 145 and Firefox 152 releases, and the WebP vs AVIF vs JPEG XL comparison for choosing between them today.

---

Sources: Chrome 145 release notes · ChromeStatus: JPEG XL decoding in Blink · libjxl/jxl-rs · Chromium issue 40168998 · Mozilla bug 1539075