Firefox 157 Makes JPEG XL Impossible to Ignore

Firefox 157 ships JPEG XL enabled by default. The sleeper feature: losslessly shrink existing JPEGs ~20% — and reverse it bit-exact.

Dafallah Ibrahim

— 2 min read
Share

Firefox 157 will ship with JPEG XL enabled by default on every platform, per Mozilla's dev-platform post. Safari already ships it. Two of the three major engines in means this stopped being a format-war footnote.

But the part you should act on today has nothing to do with browsers. JPEG XL can recompress the JPEGs you already have — losslessly, reversibly, typically around 20% smaller. No quality review needed, because the pixels never change.

Why this matters

Images dominate page weight, and most teams already burned a sprint on an AVIF pipeline. AVIF is strong at aggressive compression but falls apart at high quality and is mediocre at lossless. JPEG XL wins on both ends: smaller files at visual parity in the high-fidelity range, proper lossless mode, native HDR and wide gamut, and compressed ICC profiles built in.

The killer feature for most shops is simpler: a one-pass, zero-risk shrink of every existing JPEG. That's a storage and CDN bill line item, not a re-encode project with a QA phase.

How it works

JPEG XL has two modes. VarDCT is the perceptual mode, like AVIF's approach. Modular mode is the lossless workhorse. When you feed a JPEG to the encoder, it does something smarter than either: it parses the existing DCT coefficients and entropy-codes them with a better model.

Nothing is re-rendered, so there's no generation loss. And it's a true transform — the decoder can reconstruct your original JPEG byte-for-byte. Think of it as a better zip for JPEGs, not a new export.

JXL is also progressive by design: one file decodes at multiple resolutions, and decoding a small region or thumbnail is cheap. That threatens the "generate six resized variants" step in your image pipeline.

Where this helps

  • Legacy media libraries. Transcode millions of stored JPEGs losslessly and cut object storage and egress costs with zero perceptual risk.
  • Product photography. The high-quality range is exactly where AVIF struggles and JXL pulls ahead — smaller files at the same visual fidelity.
  • LCP on slow connections. Progressive decode paints a recognizable image from partial bytes, improving perceived load on throttled mobile.
  • Photo portfolios. Float HDR and wide gamut in one file, no sidecar color hacks, no separate "pro" variant.

Watch out

Chrome shipped JXL behind a flag, then ripped it out in 2023 and has shown no appetite for reversing course. Verify current status on caniuse before serving it unconditionally; use <picture> fallbacks or Accept negotiation at your CDN.

Tooling is patchy. You need libjxl for the CLI tools; recent sharp and ImageMagick builds handle it, older ones don't. Check your CI image before assuming.

And transcode gains vary — aggressively mozjpeg-optimized files shrink less. JXL decode is also heavier than baseline JPEG, so benchmark LCP on low-end Android before swapping formats wholesale.

Try it yourself

# macOS: brew install jpeg-xl | Debian/Ubuntu: apt install libjxl-tools
cjxl product.jpg product.jxl      # lossless transcode of existing JPEG
ls -l product.jpg product.jxl     # typically ~15-20% smaller
jxlinfo product.jxl               # inspect the file
djxl product.jxl restored.jpg     # reconstruct original JPEG
cmp product.jpg restored.jpg && echo "bit-exact roundtrip"

# true JXL encode (visually lossless, far smaller):
cjxl shot.png shot.jxl -d 1 -e 7

TL;DR

  • What changed: Firefox 157 enables JPEG XL by default on all platforms — Gecko joins WebKit, leaving Chrome as the outlier.
  • Why it matters: lossless JPEG transcoding shrinks your existing image library ~20% with zero quality risk, fully reversible.
  • Try today: run cjxl over a sample of your production JPEGs and measure real savings before the meeting where someone proposes re-encoding everything.

Read more