Chrome ships JPEG XL by default, three years after killing it

Chrome 155, which reached stable on 6 October, decodes JPEG XL (.jxl) images without a flag — the format is now on by default, no opt-in required. That’s a reversal: Chrome shipped experimental JPEG XL support behind a flag in 2021, then deleted the code entirely in 2023, citing too little interest from the ecosystem. The Chromium tracker issue for that removal drew over 1,000 comments, nearly all against it. Google quietly brought the format back behind a flag in Chrome 145 this February; 155 is the version that switches it on for everyone.

The new decoder is a rewrite in Rust (jxl-rs) rather than C++, built for memory safety with its own SIMD layer, and Chrome’s blog says fuzzing has turned up no memory-safety bugs so far. It puts JPEG XL’s compression 30-50% ahead of JPEG, with a lossless mode, HDR and progressive decoding on top, and recommends testing both AVIF and JPEG XL rather than committing to one. Safari has decoded JPEG XL since 2023. Firefox 158 is due to switch it on by default on 13 October, which would put all three major engines on JPEG XL within the same fortnight for the first time.

Why it matters: if you maintain <picture> fallbacks for AVIF and WebP, .jxl is now worth adding as a source, particularly for photo-heavy pages where its lossless mode and compression edge matter most.

<picture>
  <source srcset="photo.jxl" type="image/jxl">
  <source srcset="photo.avif" type="image/avif">
  <img src="photo.jpg" alt="…">
</picture>

The caveat: this is Chrome’s second attempt at shipping the format by default, and Firefox’s rollout is still scheduled rather than live — test before you rely on it, and keep a JPEG or WebP fallback either way.