Shipping JPEG XL in Chrome

Original Article ↗ Hacker News Discussion ↗

Google’s decision to (re)enable JPEG XL in Chrome is seen as a major turning point for the image format, which promises better compression, high‑bit‑depth and HDR support, progressive loading, and even lossless transcoding from legacy JPEGs. Commenters debate how JPEG XL compares to AVIF and WebP, weighing compression efficiency, lossless performance, decode speed, and real‑world tooling, while also highlighting past security concerns and the politics behind Google first dropping and now restoring support. Many expect that with backing from major browsers, OS vendors, and even the PDF ecosystem, JPEG XL could become a long‑term, general‑purpose successor to today’s fragmented mix of JPEG, PNG, WebP, AVIF, and HEIC.

History and motivation for JPEG XL in Chrome

  • JPEG XL support was added to Chrome, removed around 2023, and is now being re‑added.
  • Earlier removal was officially attributed to low demand and redundancy with AVIF/WebP; some commenters think security cost, internal politics, or consortium politics (AVIF/AOM) also played roles.
  • Reversal is attributed variously to: a safer Rust decoder (jxl‑rs), broader ecosystem traction, Apple/Safari support (including iPhone ProRAW JXL), and PDF spec updates adopting JXL, which effectively force browser support for PDF rendering.

Technical properties and comparisons (AVIF, WebP, PNG, JPEG)

  • Many see JPEG XL as a “general‑purpose successor” to JPEG/PNG/WebP/AVIF:
    • Lossy and lossless, high bit depth (HDR), wide color gamut, extra channels, layers, pages, animation, depth maps.
    • Lossless recompression of existing JPEGs with smaller size and no generational loss.
  • Several report JPEG XL beating AVIF/WebP/PNG for high‑quality photos and lossless use, including large file sets and machine‑vision datasets.
  • Others argue AVIF is more efficient for very low bitrates and “web hero images,” and that modern AVIF encoders have closed much of JXL’s perceived advantage.
  • A detailed “case against JXL” argues:
    • AVIF is better for typical web lossy use.
    • JXL’s lossless gains over WebP (~10–13%) don’t justify higher decode cost.
    • JPEG transcoding gains may be offset by slower decode on clients.
  • Counterpoints: many benchmarks and practical tests in the thread show JXL winning on quality/size for photos and lossless, with jxl‑rs now competitive or faster than libjxl C++.

Security and implementation

  • Original C/C++ libjxl had multiple vulnerabilities and was considered too large an attack surface.
  • Chrome and Firefox are adopting a Rust decoder to satisfy internal “rule of two” security guidelines (memory safety vs sandboxing vs trusted input).
  • Some debate whether Rust alone is sufficient without sandboxing.

Ecosystem, UX, and compatibility

  • Browsers: Safari ships JXL (without some advanced features like progressive animation); Chrome stable now; Firefox enabling by default in an upcoming release. Android WebView is expected to follow Chrome.
  • OS/apps: macOS/iOS system viewers, some editing tools, and PDF stacks support JXL; tooling quality is uneven (some encoders seen as poor).
  • Many complain about past WebP/HEIC compatibility pain (LMSes, Telegram, Instagram, desktop apps), and fear another fragmentation round; others note JXL adoption outside browsers is already faster than WebP’s was.
  • Progressive rendering is praised for removing the need for many thumbnails, but some worry about UX (unclear when loading is “done”) and potential misuse if thumbnails diverge from final images.

Adoption and deployment concerns

  • Web developers watch caniuse percentages; several won’t use JXL until ~80–90% support or at least the next Firefox ESR.
  • Encoding cost is a major concern for dynamic or on‑the‑fly pipelines; previous AVIF experiments caused large CPU and cost increases.
  • Recommended patterns include serving JXL via <picture> with JPEG/PNG/WebP/AVIF fallbacks, and waiting a few browser release cycles before widespread production use.

Broader philosophy

  • Some want a single, modern “just use this” image format; others prefer a small, purpose‑built set (e.g., AVIF for web lossy, PNG/WebP for lossless).
  • Skeptics argue JPEG/PNG remain “good enough” and universally compatible; proponents emphasize mobile data savings, storage, better quality, HDR/bit‑depth needs, and long‑term archival value.