Chrome Ships JPEG XL — Your JPEGs Can Shrink 20%

Chrome now ships JPEG XL. You can losslessly shrink every existing JPEG by ~20% — pixel-identical. Here's how to adopt it safely.

Dafallah Ibrahim

— 2 min read
Share

Chrome is shipping JPEG XL. That ends a years-long standoff: Safari supported the format, Chrome ripped its flag out back in 2023, so no sane team could actually use it. With both browsers on board, JPEG XL finally has a real audience.

Here's the part most teams miss: you don't need to re-encode, re-review, or redesign anything. JPEG XL can losslessly re-wrap your existing JPEGs — pixel-identical output, typically 15–20% smaller files. It's free bandwidth on assets you already shipped.

Why this matters

Images are still the heaviest thing on most pages, and they're usually the largest element dragging down your LCP. JPEG XL compresses better than JPEG, WebP, and generally AVIF at the same perceived quality — and it encodes far faster than AVIF's slowest modes.

It's also one format instead of three: lossy, lossless, animation, HDR, and wide gamut all live in the same container. The WebP-versus-AVIF-versus-PNG fragmentation problem mostly evaporates.

How it works

The reference tool is cjxl. Quality is controlled by distance (-d): 0 means lossless, 1 means visually lossless. Effort (-e) trades encode time for file size, 7–9 is where the wins are.

The party trick is JPEG transcoding: feed cjxl a .jpg and it stores the image in a form that reconstructs the original JPEG bit-exactly. Same pixels, same artifacts, smaller file. Decoders can even hand back the original JPEG bytes if needed.

On the serving side, browsers that support it now advertise image/jxl in their Accept header, so CDN content negotiation just works — or use <picture> with <source type="image/jxl"> ahead of your JPEG fallback.

Where this helps

  • Product catalogs: batch-transcode millions of JPEGs with zero visual QA, because the output is pixel-identical.
  • Hero and editorial images: encode from lossless masters at -d 1 -e 8 and routinely beat your current JPEGs by half.
  • Animations: one animated JXL replaces GIF, APNG, and WebP workarounds.
  • Archives: lossless JXL also beats PNG handily for screenshots and technical images.

Watch out

Firefox has historically refused JPEG XL — verify its current status before you call the format baseline, and always keep a JPEG fallback.

Your pipeline may not be ready: check whether sharp, your image CDN, and your build tooling can encode or transform JXL before committing. And remember you're now maintaining two files per image, so automate the transcode rather than doing it by hand. Keep your original masters either way.

Try it yourself

# install the reference encoder
brew install jpeg-xl   # or: apt install libjxl-tools

# losslessly transcode an existing JPEG (pixel-identical)
cjxl product.jpg product.jxl

# encode a lossless master at near-lossless quality, high effort
cjxl hero.png hero.jxl -d 1 -e 8

# measure the damage
ls -l product.jpg product.jxl hero.png hero.jxl

TL;DR

  • What changed: Chrome is shipping JPEG XL, joining Safari — the format war finally has a winner with reach.
  • Why it matters: every existing JPEG can shrink ~20% losslessly, and new images compress better than AVIF or WebP.
  • Try today: run cjxl over ten real assets from your site and measure — then wire up a <picture> fallback.

Read more