Firefox 157 will include JPEG XL by default on all platforms

Original Article ↗ Hacker News Discussion ↗

Firefox 157 and upcoming Chromium releases are enabling JPEG XL image support by default, signaling a major shift toward this newer format across mainstream browsers. Commenters weigh JPEG XL’s technical advantages over JPEG, WebP, and AVIF—such as lossless recompression of existing JPEGs, strong lossless and lossy compression, progressive decoding, high bit depths, and huge image sizes—against practical hurdles like tooling, OS-level support, and website upload constraints. There is also debate over implementation choices (Rust vs. C++), the security and performance of the new decoders, and how ecosystem drivers like Apple’s early adoption and the PDF standard influenced JPEG XL’s revival.

What JPEG XL offers

  • Losslessly recompresses existing JPEGs, typically shrinking them ~15–30%, while allowing bit‑exact reconstruction of the original JPEG.
  • Supports both efficient lossy and lossless compression, including high bit depths (10/12/16‑bit, float), HDR, wide gamut, alpha, layers, animation, thumbnails, and very large images (up to ~1M×1M pixels).
  • Strong progressive decoding: can deliver useful thumbnails and partial‑quality views from the first fraction of the file; can mix lossless and lossy regions and multiple extra channels (e.g., for 3D materials).

Comparison with WebP and AVIF

  • Lossless: generally compresses better than WebP and much better than AVIF; AVIF’s lossless mode is described as effectively unusable.
  • Lossy:
    • WebP often beats JPEG but shows banding and artifacts at gradients; good for web but not ideal archival.
    • AVIF tends to win at very low bitrates but lacks progressive loading.
    • JPEG XL is competitive or better at normal web-quality bitrates, but the exact advantage is disputed.
  • WebP has strong ecosystem support today; JPEG XL seen by some as “best of all worlds” if support matures.

Browser and library support

  • Firefox 157 and Chromium will ship JPEG XL by default using a Rust decoder (jxl‑rs).
  • Apple previously shipped support via the C++ reference implementation in Safari and system libraries, which many see as a key catalyst.
  • PDF standard is adding JPEG XL, especially for HDR and very high‑res images, which also pressures browser support.

Performance, safety, and implementations

  • Lossless JPEG XL compresses better but typically decodes more slowly than lossless WebP.
  • Some users report slow thumbnails and browsing for JXL images on macOS, suggesting current platform implementations may be immature.
  • Rust decoder (jxl‑rs) recently surpassed the C++ libjxl in decoding speed; C++ still used for encoding.
  • Major browsers favor Rust for memory safety when decoding untrusted image data; C++ seen as higher risk, though not fundamentally slower.

Adoption hurdles and skepticism

  • Many tools, OS explorers, and web upload pipelines still only handle JPEG/PNG/WebP.
  • Some consider JXL overhyped, offering only marginal real‑world gains and adding format complexity.
  • Others are optimistic it can eventually replace JPEG/PNG/GIF, but note that ecosystem and upload support will be the long tail.