Chrome 155 will decode JPEG XL images natively, ending a years-long saga in which Google first added, then removed, then finally re-added support for the next-generation image format. The announcement buries the lede: the decoder shipping is not the original C++ reference implementation (libjxl) but jxl-rs, a ground-up rewrite in Rust. That choice tells you more about where browser engineering is headed than the format itself. JPEG XL promises 30-50% better compression than JPEG, lossless compression, HDR support, progressive decoding, and — critically for the billions of existing JPEG files on the web — lossless transcoding from legacy JPEG. The format competes with AVIF, and Chrome's own recommendation hedges: try both, but expect JPEG XL to win on high-fidelity photographic content and fine-grained progressive loading. The two formats are complementary more than rivalrous. The security architecture is the most consequential decision in the announcement. Image decoders parse complex untrusted binary data from the open internet inside the renderer process — one of the fattest attack surfaces in any browser. Chrome's team explicitly invoked the Rule of Two, which holds that code touching untrusted input in an unsafe language inside a privileged process is unacceptable. Rather than sandbox a C++ decoder and hope, they eliminated the vulnerability class at the source by rewriting in Rust. They report zero memory-safety bugs across the entire implementation history, validated by fuzzing and AI-assisted code review. Performance parity was non-negotiable. The Rust rewrite needed to match or approach libjxl's speed, which meant full SIMD utilization. This required stabilizing Rust's targetfeature11 feature to allow safe SIMD dispatch without unsafe blocks, plus building a new SIMD abstraction layer (jxlsimd) modeled on the C++ Highway library. The result is a multi-platform decoder that doesn't compromise on vectorized performance while confining unsafe operations to a small, auditable surface. Chrome tracks this on a public performance dashboard. The developer feedback loop matters here. JPEG XL was a perennial request through Chrome's bug tracker, developer surveys, the Developer Signals Project, and most visibly through the W3C Interop Project, where it was a popular proposal in 2026 and several prior years. Chrome's reversal — having removed an earlier JPEG XL flag — was a visible case of developer community pressure overriding an internal cost-benefit calculus. The Interop 2026 investigation ensured cross-browser test coverage for the full feature set before shipping. This is a generative move for the web platform. It adds genuine new capability (HDR, lossless transcoding, better compression) without extracting rent, ships in a memory-safe implementation that raises the security floor for all users, and validates a model — Rust rewrites of critical C++ attack surfaces — that Chrome and other browser vendors will almost certainly repeat for other codecs and parsers. The friction cost is real but contained: developers must now decide between AVIF and JPEG XL, and CDN/toolchain support will take time to catch up. The 20-year view is straightforward. If this pattern holds — community pressure via Interop, memory-safe reimplementation as prerequisite, performance parity as hard constraint — the web's media stack gets both safer and more capable over time. The alternative, in which new formats ship as C++ and accumulate CVEs, is the world this decision is designed to end.
