AI Weekly Malaysia

Chrome is shipping decode support for JPEG XL (.jxl) starting in Chrome 155, per a Chrome for Developers blog post published October 6, 2026 by Luca Versari, Moritz Firsching, and Philip Jägenstedt. The post claims 30-50% better compression than JPEG plus lossless compression, built-in HDR support, and lossless JPEG transcoding, and says Chrome recommends trying both AVIF and JPEG XL rather than picking one. The decoder is a from-scratch pure-Rust implementation (jxl-rs) with a SIMD abstraction layer (jxl_simd) inspired by the C++ Highway library from libjxl, which required stabilizing the Rust target_feature_11 feature so SIMD could be used without unsafe code.

Why: This is decode-only, so it changes what you can accept from users and third parties, not what you can cheaply produce: if your pipeline already handles AVIF, Chrome 155+ means you can serve .jxl to Chrome clients and keep AVIF/JPEG fallbacks for everything else, and you can A/B the two on your own photographic or lossless assets instead of trusting the 30-50% claim. The Rust-rewrite detail is the transferable one for anyone shipping a parser of untrusted binary input: Chrome's stated reason is that C++ decoders have historically produced out-of-bounds reads, heap overflows, and use-after-free bugs, and sandboxing is treated as only a secondary layer.