Chrome Killed JPEG XL in 2023. Chrome 155 Ships It by Default.

The short version: what changed this week

Google published the announcement on October 6: Chrome 155 ships JPEG XL decoding turned on by default. No flags, no experiments, no excuses. Any .jxl image (MIME type image/jxl) now renders directly in web pages on the world's most-used browser.

This is not a minor codec footnote. JPEG XL promises 30–50% smaller files than classic JPEG at equivalent quality, plus lossless compression, built-in HDR, animation, and — the sleeper feature — lossless transcoding of your existing JPEGs, meaning archives can be recompressed bit-for-bit reversibly. Google's own guidance is honest rather than triumphalist: try both AVIF and JPEG XL, because which wins depends on the image. JXL's sweet spot is high-fidelity and lossless compression of photographic images, and cases where fine-grained progressive decoding matters.

The timing is what makes this a story rather than a changelog line. Google removed experimental JPEG XL support from Chrome in early 2023. Developers spent the next three years asking for it back — it was one of the most popular proposals in the Interop 2026 process. Chrome 145 (February 2026) quietly reintroduced decoding behind the flag chrome://flags/#enable-jxl-image-format, where almost nobody toggles things. Chrome 155 is the release that flips the switch for everyone. Mozilla is on the same train: Firefox 158 enables JPEG XL by default in mid-October. Safari, notably, has supported the format since 2024.

Why Google killed it in 2023 — and what changed

The 2023 removal was never about the format. It was about the decoder. Image decoders are among the most attacked code in any browser: they chew through untrusted binary data straight off the network, inside the renderer process. The reference implementation, libjxl, is C++ — and historically, C++ decoders are where out-of-bounds reads, heap overflows, and use-after-free bugs live. Google didn't want that attack surface, and at the time the team also wanted a long-term maintenance commitment before shipping anything.

The fix was to rewrite the decoder in Rust. Chrome 155 ships jxl-rs, a pure-Rust implementation. The Chrome team's post is explicit about the security reasoning: sandboxing is a secondary layer of defense; eliminating the bug class at the source is better. And they went further than "we rewrote it in Rust and called it a day." A big chunk of codec performance comes from SIMD instructions, and using those in Rust used to require unsafe blocks — so the team got the target_feature_11 feature stabilized first, built a SIMD abstraction layer (jxl_simd) inspired by the Highway library, and restricted unsafe to a small number of heavily reviewed locations. Then they fuzzed the implementation, put it through AI-assisted code review, and report finding zero memory-safety bugs in its entire implementation history.

That last detail is worth pausing on. The argument "rewrite it in Rust" gets thrown around a lot; this is one of the cleaner real-world receipts for it — a hot-path media decoder, performance-competitive with the C++ reference, with a public performance dashboard to prove it.

What JPEG XL actually buys you (and where it doesn't)

The headline number — 30–50% smaller than JPEG — is Google's comparison against the 1992 original, not against modern codecs. Against AVIF, the picture is genuinely murky: one widely cited benchmark found JPEG XL about 11% smaller with 13% higher measured quality, while an AVIF-focused developer's independent tests favored AVIF in his range. The honest reading is Google's: try both on your own images. No codec wins every photo.

Where JXL is clearly differentiated:

Lossless JPEG transcoding. Existing JPEGs can be recompressed into JXL losslessly and converted back bit-for-bit. For anyone sitting on terabytes of photo archives or user uploads, that's a migration path that doesn't require re-encoding from originals you may not have.
Fine-grained progressive decoding. JXL can stream a recognizable image absurdly early and refine it — the Chrome announcement includes a side-by-side demo. On slow connections this is the difference between a blank box and a usable page.
HDR, wide gamut, high bit depth, and animation in one container, standardized as ISO/IEC 18181. One format covering photography, print-ish fidelity, and motion.
Encode/decode speed. Roughly as fast as old JPEG with libjpeg-turbo, and an order of magnitude faster than HEIC with x265.

Where it isn't magic: tooling. AVIF has a multi-year head start in encoders, CDN integrations, and CMS plugins. And Safari's two-year head start on JXL support didn't trigger a mass migration, which tells you browser support alone doesn't move the web — workflows do.

The catch: rollout math

Don't rewrite your image pipeline tonight based on a version number. Chrome updates roll out in the background over days to weeks, enterprise fleets pin versions, and Edge, Samsung Internet, and other Chromium browsers ship on their own schedules. One tracker measured global JPEG XL support at roughly 17% on October 7 — almost entirely Safari. That number climbs through October and November as Chrome 155 and Firefox 158 reach installed browsers, but "Chrome shipped it" and "your visitors can see it" are different statements for at least a few more weeks.

Also note the quiet condition Google set: the team required a long-term maintenance commitment and standard launch criteria before enabling the decoder by default. Reading between the lines, this is Google saying the 2023 episode taught them something — shipping a codec is a decade-long promise, not a release note.

(One more Chrome 155 footnote for the security-minded: the same release adds post-quantum cryptography algorithms to the Web Crypto API — ML-KEM for key exchange, ML-DSA for signatures, plus ChaCha20-Poly1305 and X-Wing. The browser is quietly getting ready for a post-quantum world while you're reading about image formats.)

What to do this week

This is a low-risk, high-upside change if you do it the boring way — with fallbacks, not flag days:

Serve JXL as a progressive enhancement. The <picture> element exists for exactly this. Add a <source type="image/jxl"> ahead of your AVIF/WebP/JPEG fallbacks and let the browser pick what it can decode. Zero breakage, instant wins for Chrome 155+ and Safari visitors.
Benchmark on your own images. Encode a representative sample — heroes, thumbnails, product shots — with cjxl (or Sharp/libvips, which support JXL) at your usual quality settings, and compare against your current AVIF output. Google's "try both" advice is the whole game; don't take anyone's benchmark as gospel.
Check your analytics before you touch anything. If a big slice of your traffic is on pinned enterprise Chrome or older Android WebViews, your JXL coverage will lag the headline.
Don't bulk-convert archives yet. The lossless JPEG transcoding story is real, but validate the round-trip tooling on a copy first, and keep originals until the tooling has another year of battle-testing.

<picture>
  <source srcset="hero.jxl" type="image/jxl">
  <source srcset="hero.avif" type="image/avif">
  <img src="hero.jpg" alt="Product hero shot" loading="eager" fetchpriority="high">
</picture>

The broader lesson is the one the Chrome team spelled out: this shipped because developers kept asking, through bugs, surveys, and the Interop process, for three straight years. The 2023 removal felt like a verdict on the format. It turned out to be a verdict on the decoder — and once the decoder got rewritten in memory-safe Rust, the verdict changed. Formats don't die when companies lose interest; they die when nobody maintains them. Somebody maintained this one.