JPEG XL 2026: What Firefox 157 and Chrome Plan to Ship
Mozilla and Chrome posted JPEG XL ship intents on 24 August. Firefox 157 is the dated window; jxl-rs is the decoder.
On 24 August 2026, Mozilla posted an Intent to Ship for JPEG XL on Mozilla Hacks: decode on by default in Firefox 157, aimed at late September. The same day, Chromium filed its own intent to ship JPEG XL decode in Blink. This is a format story, not a how-to for mics or screen share.
The search query is JPEG XL 2026 Firefox Chrome default decode. Safari has decoded the format since 2023. Chrome ripped out even experimental support in 2022. The reversal rests on jxl-rs, a Rust decoder from Google Research — not on resurrecting the old ~100,000-line multithreaded C++ reference decoder.
Who shipped what, and when
Jake Archibald wrote that Firefox had JPEG XL behind a flag in 2021, but would not default-enable a decoder that large. Mozilla challenged the JPEG XL team at Google Research: build a safe, fast, compact, compatible Rust decoder, and Firefox would ship. They delivered jxl-rs. It is now the core of Firefox’s implementation and the decoder Chrome’s intent also names. Phoronix reported the same day that Nightly already has it on for vetting before 157; Chrome’s posting did not lock a stable version for every user.
Mozilla
Intent to Ship: default decode on all platforms in Firefox 157. Nightly is already on. Source: Mozilla Hacks, 24 Aug 2026.
Chromium / Chrome
Intent to ship Blink decode on the same Rust decoder. A commitment to ship, not proof it is already on for everyone.
Safari
JPEG XL since 2023. Archibald notes the Safari implementation still lacks progressive rendering that Firefox cares about.
The blocker was the decoder
JPEG XL can losslessly recompress existing JPEGs (figures around 20% are commonly cited) and can show the subject after only a sliver of the file arrives. Browsers stalled on attack surface: images are untrusted, high-variance input. Mozilla set a bar a C++ reference could not clear; Google Research cleared it in Rust.
JPEG XL versus AVIF
Archibald’s own samples: for typical lossy web photos, AVIF is usually smaller; JPEG XL wins at lossless and at recompressing legacy JPEGs. AVIF’s progressive story is weak, so huge images may still justify JPEG XL. Test your own set.
| Job | AVIF | JPEG XL |
|---|---|---|
| Lossy web photos | Usually smaller | Often larger at like quality |
| Lossless / JPEG recompress | Weaker fit | Stronger fit |
| Progressive paint | Basic | A Firefox priority |
What this has to do with a browser room
Codec news lives in the image pipeline. Short co-creation still means open a browser, share one page, finish the drawing. If you care whether phones join cleanly, read
mobile browser notes. If you only need one shared picture,
keeping the canvas on one page matters more than .jxl. To open a room now, go to the
rtcroom home page.
Still wondering?
Does Chrome stable decode JPEG XL for everyone today?
The 24 August 2026 action is an Intent to Ship. Chromium merged jxl-rs earlier and tested behind a flag. Default-on for all stable users still depends on a later release note.
What is jxl-rs?
A Rust JPEG XL decoder from Google Research. Mozilla made it a ship condition. Firefox and the planned Chrome path use it instead of the pre-2022 C++ decoder.
Should sites migrate from AVIF now?
No. Mozilla’s own comparison still favors AVIF for typical web photography. Wait for Firefox 157 and Chrome defaults, then measure. CDNs and CMSes will lag browsers.