A 313-point Hacker News discussion has made an image codec rollout look like browser trivia. For developers, the useful signal is narrower and more immediate: a JPEG XL file may soon render without a flag in Firefox and Chromium-based browsers, leaving fallback strategy rather than browser ideology as the practical problem.
Mozilla engineer Timothy Nikkel said Firefox 157 is set to enable JPEG XL decoding by default on every supported platform. The decoder has been available behind image.jxl.enabled, enabled by default in Nightly, and exposed through Firefox Labs since version 152. Mozilla is using jxl-rs, a decoder written in Rust.
The timing became more interesting when Chromium posted its own intent to ship JPEG XL using the same Rust decoder. Chromium's proposal covers Windows, macOS, Linux, ChromeOS, Android, and Android WebView, but it names no release milestone. Safari has decoded JPEG XL since version 17.0, according to Mozilla's announcement. If both new plans reach stable releases, all three major browser engines will have a path to the format. That is still an if.
One Rust decoder, two browser engines
Firefox and Chromium converging on jxl-rs matters because image decoders process files supplied by websites, messages, and uploads. The jxl-rs project describes its implementation as mostly safe Rust, with reviewed unsafe code retained where SIMD and other performance work require it. WebKit uses the C++ libjxl decoder, while the two other engines are moving toward the Rust implementation.
The Chromium intent says the Rust and C++ decoders are tested against the same conformance corpus. Their browser integrations still differ. Memory limits, incremental input, color management, animation timing, and damaged files surround the decoder itself. Mozilla's test set includes different bit depths, alpha, grayscale and CMYK images, as well as incremental decoding and corrupt inputs. Its fuzzing team tested jxl-rs before the Nightly switch and plans another pass before the preference changes for stable users.
Using one decoder in two engines can make bugs easier to reproduce. A malformed file that reaches the same library through both browsers gives maintainers a smaller search area, even though each browser may feed and display the result differently. It creates a shared dependency too. A decoder regression could affect two engine families, so independent browser tests remain useful even when the underlying Rust crate is the same. The shared maintenance benefit comes with that correlated risk.
What JPEG XL changes for image delivery
JPEG XL is ISO/IEC 18181, a format aimed at web images and photography. The JPEG committee's overview lists lossy and lossless coding, progressive display, animation, alpha channels, wide color, high bit depth, and HDR among its supported features. A browser adding a decoder does not automatically give every feature equal treatment, but the format covers more than a smaller JPEG replacement.
Its migration story is unusual. An existing JPEG can be transcoded into JPEG XL without changing the image data, then restored to the exact original JPEG. A service can therefore keep one compressed JPEG XL representation while recreating a legacy JPEG for clients that need it, according to the JPEG committee. Whether that saves money depends on the archive, delivery stack, and compute cost. The reversible path removes the need to accept another round of visual loss when testing the format against a large JPEG collection.
Progressive decoding is the part users may notice. A conforming file can reveal an increasingly detailed image as bytes arrive, instead of waiting for the complete download or relying on a separate low-resolution placeholder. Chromium cites perceived loading performance as one reason for support. Mozilla says its implementation handles progressive display and animation, while HDR JPEG XL images currently display as SDR in Firefox. The same announcement says Safari's implementation lacks progressive rendering and animation, so a .jxl file rendering in all browsers will not mean every presentation mode behaves alike.
A static product photograph is a simpler test target than an animated asset, and an SDR screenshot says little about an HDR photography workflow. Teams evaluating JPEG XL should test the specific files they intend to serve on actual browser builds. The different feature levels described by Mozilla mean a green compatibility box cannot verify color, decode time, memory use, or the first useful paint for a site's own image set.
Decode speed is still the uncomfortable question
Mozilla's intent addresses performance directly. Nikkel reports that jxl-rs 0.6.0 added multithreaded decoding and that Firefox integration patches are expected to enable it. In his five-format test across multiple image sizes, the Rust decoder ran slightly ahead of Safari's C++ decoder on his machine. He also found JPEG XL close to Firefox's other decoders on large images, with a wider gap on small ones. Those are one engineer's measurements, not a promise for every phone or laptop.
A reply in the same Mozilla thread supplies a sharply different data point. Sergey Davidoff tested one lossless image in single-threaded command-line decoders and measured WebP at 30.93 times the speed of jxl-rs, while the JPEG XL file was about 10 percent smaller. He also measured libjxl at roughly 20 times slower than WebP for that case. The test is useful because it exposes a bad workload, but one image and CLI tools cannot settle browser performance across lossy photos, thumbnails, larger images, or multithreaded builds.
The deployment benchmark should ask whether JPEG XL reduces enough transferred or stored data to repay its decode cost on the devices that receive it. Small interface assets could behave differently from large photographs. Server archives have different priorities again, especially when reversible JPEG transcoding is involved. Mozilla says its decode benchmarks report to Perfherder; those results and post-release telemetry should be more informative than a single format-wide verdict.
Keep the fallback even after Firefox 157
The lowest-risk deployment uses HTML's <picture> element. MDN documents how a browser checks each <source> and falls back to the nested <img> when it cannot use the offered format. A basic JPEG XL trial can keep WebP and JPEG behind it:
<picture>
<source srcset="photo.jxl" type="image/jxl">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="Product photographed from the front">
</picture>
That markup lets current browsers skip an unsupported JPEG XL source without a JavaScript capability test. It also keeps the page usable if a browser vendor delays or reverses a rollout. MDN assigns the fallback role to the nested <img>. Teams should retain the dimensions, alt text, cache policy, and loading behavior they already apply there. Format support does not repair layout shift or an oversized source image.
Do not read Firefox 157 as permission to delete the alternatives. Mozilla's message is an intent to change a preference, with testing and the default switch still ahead when it was posted. Chromium has declared an intent but no milestone. Even after releases land, a site's visitors will include older browsers, embedded webviews, and managed devices on delayed update schedules. The fallback can become less busy later, once traffic data shows which branches no longer earn their storage and build cost.
Mozilla still records a neutral standards position on JPEG XL, despite preparing to ship it. Implementation and endorsement are different decisions. The next evidence to watch is concrete: Firefox's default-on patch and stable release behavior, Chromium's approval and named milestone, then decode and memory results from ordinary devices. Those results will tell developers when JPEG XL is ready to move from an optional first source to the default asset in their image pipeline.