For five years, JPEG XL sat in a strange limbo: a genuinely better image format, backed by an ISO standard, supported by Safari, and ripped out of Chrome in 2022 for lack of "sufficient interest." That standoff ended this week. Chrome 155 shipped to stable on October 6 with a built-in JPEG XL decoder, and Firefox 157 followed with native support of its own — meaning every major browser engine except legacy Edge-on-old-Chromium now understands .jxl files out of the box. For teams doing production frontend engineering, that's a real shift in what "safe to ship" means for images.
Chrome's JPEG XL decoder, rebuilt from scratch in Rust rather than reviving the old C++ implementation, now decodes .jxl images directly in <img>, CSS backgrounds, and canvas — no flag required. Neowin's coverage of the release notes that the Rust rewrite was specifically motivated by memory-safety concerns: image decoders are a classic attack surface, and a C++ JPEG XL implementation had already produced CVEs elsewhere. Firefox 157 ships native decoding on the same general timeline, which means Safari (since 2024), Chrome, and Firefox are now aligned — the three-way split that made JPEG XL unsafe to rely on in production has effectively closed.
JPEG XL's pitch has always been the same: 30–50% smaller files than baseline JPEG at equivalent visual quality, lossless recompression of existing JPEGs with no quality loss, progressive decoding, wide color gamut, high bit depth, and native animation — one format instead of separate JPEG, PNG, and GIF pipelines.
Practically, this doesn't change anything you ship today — JPEG XL isn't a drop-in replacement you flip a switch for, and you still need a fallback for older browsers and the long tail of Chromium forks that haven't caught up. What it does change is the calculus for your next image pipeline decision:
<picture> fallback.<picture> with a type="image/jxl" source and a JPEG or WebP fallback is still the correct pattern — treat JPEG XL the way you treated AVIF two years ago, as an enhancement, not a baseline.Stable-channel users on Chrome 155 and Firefox 157 have JPEG XL decoding right now; both releases went to stable in the first half of October 2026. Enterprise and extended-support channels lag a release cycle or two behind, and any Chromium-based browser that pins to an older base (some embedded WebViews, some legacy enterprise builds) won't pick this up until it rebases. The JPEG XL project's own news page is the most reliable place to track which build of which browser actually has it, since "ships in Chrome" and "reaches your users" are measured in different calendars.
None of this is urgent. JPEG XL support is a tool you now have, not a migration you owe anyone. But it's the first time in years that reaching for it in production doesn't mean betting on one browser vendor's roadmap.