Firefox to Enable JPEG XL Decoding by Default in Version 157
Mozilla plans to turn JPEG XL decoding on by default in Firefox 157 across all platforms, with the release scheduled for late September 2026. The announcement, posted to the Mozilla dev-platform mailing list on August 25, 2026, is the most concrete step yet toward shipping the ISO/IEC 18181 image format — an international standard for a next-generation image codec — to Firefox's general user base. The enabling bug is tracked in Bugzilla as bug 2065096. Mozilla dev-platform
Firefox's JPEG XL decoder is jxl-rs, a Rust implementation. Google Chrome also uses jxl-rs for its own behind-a-flag JPEG XL support (#enable-jxl-image-format), though Chrome has not signaled intent to ship the format by default. The shared Rust library underpinning both browsers' decoders means the core parsing and rendering logic is, to a large extent, a common codebase — even as the two browser vendors remain at different points on the adoption curve. Mozilla dev-platform
Firefox has offered JPEG XL support through a preference, image.jxl.enabled, which has been on by default on the Nightly channel for some time. Since Firefox 152, a Firefox Labs checkbox has exposed the toggle on every channel (Release, Beta, and Nightly), letting users opt in without touching about:config. Firefox 157 would flip that default from opt-in to on for all channels and platforms. Mozilla dev-platform
The JPEG XL standard, formally ISO/IEC 18181, was published as an international standard by ISO. Apple's Safari shipped JPEG XL support in version 17.0, released in 2023. That puts Safari roughly three years ahead of Firefox on default-enabled delivery and leaves Chrome as the holdout among the three major browser engines. Mozilla dev-platform Phoronix
Mozilla's standards position on JPEG XL is formally neutral, recorded in its standards-positions repository as issue 522. A neutral position from Mozilla typically means the organization neither champions nor opposes the specification at standards bodies, while still reserving the option to implement it in Firefox — which is precisely the path now being taken. Mozilla dev-platform
The broader context here is the competitive dynamics among browser engines. With Safari already shipping and Firefox moving to default-on, Chrome becomes the lone major engine without a stated intent to enable JPEG XL for general users. Both Firefox and Chrome share the same Rust-based decoder, which raises an interesting question: if the implementation barrier is effectively shared, Chrome's hesitation is presumably driven by factors other than engineering cost — product strategy, partnership considerations, or a read on web developer demand. Google's prior decision to remove an earlier JPEG XL intent-to-ship from Chrome (a history that predates the verified facts here) looms over that hesitation, though the current facts only confirm the flag exists and no ship intent has been declared.
For web developers and CDNs, Firefox 157 default support narrows the gap to cross-browser JPEG XL delivery. Once Firefox ships, two of three major engines will decode the format natively. Content providers evaluating whether to serve JPEG XL — whether for bandwidth savings on photographic content, lossless recompression of existing JPEGs, or the format's support for wide gamut and high bit depth — gain a stronger case for adoption. The remaining variable is Chrome, whose global browser share makes its position the decisive factor for any broadly deployed image pipeline.
There is a familiar shape to this kind of format adoption: a format standardizes, one browser ships first, another follows, and the largest waits. AVIF followed a version of this arc. WebP did as well, though over a longer timeline. JPEG XL's trajectory is now further along than AVIF's was at a comparable stage, given that two engines will be default-enabled rather than one. Whether Chrome closes the loop is the open question. What is settled, as of this announcement, is that Mozilla has committed to the flip — and given the shared decoder, the technical risk is bounded.
