Firefox 157 will ship JPEG XL with a Rust decoder

Mozilla published its intent to ship JPEG XL on 24 August 2026, and Phoronix reports the format will be enabled by default on all platforms in Firefox 157, due at the end of September. The condition Mozilla attached is the interesting part: rather than adopt the existing C++ reference decoder, it commissioned Google Research to write a new one in Rust, and that decoder - jxl-rs - is what Firefox will ship.

Why the decoder had to be rewritten first

Mozilla describes the commission plainly in its announcement: it asked for "jxl-rs, a safe, performant, compact, and compatible JPEG XL decoder in Rust." Per Phoronix, the Rust implementation was chosen over the C++ path for both performance and security reasons, and Bugzilla records that Firefox uses jxl-rs rather than the libjxl reference implementation partly for better integration with Firefox's own architecture.

An image decoder is about the least forgiving place in a browser to run unsafe code: it parses hostile input from any site a user visits, before any sandboxing decision the page might influence. Requiring a memory-safe decoder before shipping a format is a defensible price for the format's author to pay, and it took time - Bugzilla traces the implementation effort back to 2020, and the library shipping now is version 0.6.0.

What JPEG XL is good at, and where AVIF still wins

Mozilla is unusually specific about not treating this as a format war. Its announcement says JPEG XL excels at lossless imagery, progressive rendering, and re-compressing existing JPEGs without quality loss, while AVIF is stronger on photographic images and on content that mixes sharp edges with flat surfaces.

Progressive rendering is the practical difference. Mozilla says its Firefox implementation prioritises it, with an image displayable once a few kilobytes have loaded, and the trade-off is stated bluntly in a line Phoronix quotes: "AVIF only has basic progressive rendering support. So, for very large images, it may be worth taking the filesize hit with JPEG XL." That is a rare thing in a shipping announcement - the vendor naming the case where its new format produces a bigger file.

Where support stands right now

Browser	Status
Firefox 157 (end of September 2026)	Enabled by default, all platforms (Phoronix)
Firefox 152+ / Nightly	Experimental, behind the image.jxl.enabled preference (Phoronix, Bugzilla)
Chrome	Removed support in M110 in March 2023 (Bugzilla); Google has now formalised intent to enable it by default in Blink, announced alongside Mozilla (Phoronix)
Safari	Supported in recent versions (Bugzilla)

Bugzilla lists what the Firefox implementation covers: progressive decoding, animation, colour-profile management through the CMS integration, HDR, and CMYK. It also lists what is not finished - HDR optimisation, multithreaded decoding integration, and the flip of the default preference itself are all still tracked as open work.

What this means for developers

Do not rewrite your image pipeline this month. The honest status is that Firefox has announced an intent, Bugzilla still shows the preference off outside Nightly, and the default flip is tracked as open work - so the milestone to watch is Firefox 157 actually shipping at the end of September, not this announcement.

What is worth doing now is a measurement. JPEG XL's distinctive claim is lossless re-compression of existing JPEGs, so take a real directory of your production JPEGs, re-compress a sample, and record the byte savings and the decode behaviour. That number decides whether this is worth pipeline work for your site or not, and it is specific to your images - a format comparison from someone else's photo set will not tell you.

For anything with very large images - maps, scans, product zoom, medical or archival imagery - Mozilla's own guidance points at JPEG XL even at a file-size cost, because a picture that renders usefully after a few kilobytes beats a smaller file that renders late. If that describes your product, this is the announcement to act on. If your images are ordinary photographs, AVIF remains the format Mozilla says is stronger, and the correct action is to keep your picture element fallbacks honest and wait.

The broader signal is about how formats now get adopted. A codec being good was not enough: Mozilla made memory safety a shipping condition and the format's own backers paid for a Rust rewrite to clear it. Anyone hoping to get a new media format into browsers should read that as the new baseline, and Mozilla's contribution of integration tests to web-platform-tests under Interop 2026 as the second half of the same bar.