Firefox 157 will include JPEG XL by default on all platforms
Firefox 157 is set to embrace JPEG XL by default, leveraging a new Rust-based decoder developed by Google Research, reigniting hope for the next-generation image format after its tumultuous path to widespread browser adoption. This move sparks renewed interest in JXL's technical superiority over WebP and AVIF, particularly its ability to losslessly recompress existing JPEGs. The HN community is abuzz with discussions comparing these image formats and the critical role of a safe, performant Rust implementation in its resurgence.
The Lowdown
Mozilla's Firefox 157 is slated to enable JPEG XL decoding by default across all platforms, a significant step forward for the advanced image format. This decision follows extensive development behind a feature flag and addresses prior performance concerns through the adoption of the jxl-rs Rust decoder, developed by Google Research. The initial intent to ship notes highlight that performance, particularly with multi-threaded decoding in jxl-rs 0.6.0, now positions Firefox's JXL implementation competitively, even slightly ahead of Safari's C++ version on certain benchmarks for large images.
- Default Implementation: Firefox 157 will integrate JPEG XL natively using the
jxl-rsRust decoder, which has been under development and accessible via a Firefox Labs checkbox since version 152. - Performance Evolution: Early concerns about decoding speed were largely mitigated with
jxl-rsversion 0.6.0, which introduced multi-threaded decoding support, bringing its performance close to other image decoders for large files. - Feature Completeness: The Firefox implementation boasts feature parity with Blink's JXL, including support for animation and progressive display. While HDR images display as SDR, JXL benefits from superior tone mapping compared to other supported formats.
- Rigorous Testing: The integration has undergone thorough testing, including Web Platform Tests (WPT), numerous internal Gecko tests for edge cases like chunked decoding and corrupt files, and extensive fuzzing.
- Lossless Performance Caveat: A critical point of contention raised by Sergey Davidoff within the Mozilla discussion group highlights that lossless JPEG XL decoding is significantly slower (up to 30x) than lossless WebP for a relatively minor (10%) file size reduction, suggesting a potential trade-off in user experience on less powerful devices.
This default enablement by Firefox represents a major endorsement for JPEG XL, though the ongoing debate about its performance characteristics, especially for lossless content, suggests that its journey to universal adoption may still face hurdles.
The Gossip
JXL's Jaw-Dropping Features
Many commenters enthusiastically highlight JPEG XL's advanced capabilities that set it apart from WebP and AVIF. Key features lauded include its ability to losslessly recompress existing JPEGs (saving 20-30% file size without quality loss), superior progressive decoding, and robust support for high bit-depths (10, 12, 16-bit float) and diverse color formats like CMYK. They emphasize JXL's flexibility, including handling images with mixed lossy/lossless parts and much larger dimensions than AVIF, positioning it as a more future-proof replacement for JPEG, PNG, and GIF.
Rust's Resonant Role
The discussion frequently points to the `jxl-rs` Rust implementation as a pivotal factor in Firefox's decision to adopt JPEG XL. Commenters speculate that Mozilla's challenge to Google Research to build a safe, performant Rust decoder was met, paving the way for inclusion. This raises questions about Apple's strategy, as Safari already shipped `libjxl` (C++), and whether they might eventually shift towards Rust-based implementations for consistency and safety.
Performance Ponderings
While generally optimistic, some commenters echo concerns raised in the Mozilla thread about JPEG XL's performance, particularly for lossless decoding, where it's cited as significantly slower than WebP. The discussion acknowledges WebP's current strong support and efficiency for web use cases, especially for smaller file sizes, while JXL is seen as the 'best of all worlds' once its software support and performance are fully optimized across various scenarios.