JPEG XL in Chrome: same photo, fewer bytes.

As of 2026.10, Chrome 155 decodes JPEG XL. Google announced it on 2026.10.06 and claims the format compresses photos 30–50% better than JPEG. Images are usually the heaviest thing on a page, so a format that cuts that much without a visible loss is worth a look, and with <picture> trying it costs you nothing.

Watch the 60-second version on Instagram.

The sizes in the figure are illustrative: the 30–50% range is Google's claim, not a benchmark of mine. Your saving depends on the photo and on the quality you encode at.

What shipped, exactly

Chrome 155 ships decoding only. The browser can display .jxl files; it doesn't encode them. The decoder is jxl-rs, which the Chrome team describes as a pure Rust implementation of the JPEG XL decoder. Firefox is adopting the same Rust decoder, so the two engines will share one implementation of the format.

It's also the second time around. Chrome had JPEG XL behind a flag from version 91 to 109 and removed it in 110. Google says it came back after being a popular proposal for Interop 2026, and for several years before that.

The format itself is the royalty-free standard ISO/IEC 18181, MIME type image/jxl, extension .jxl. Beyond smaller lossy photos, it brings:

• Lossless compression, for when every pixel must survive.
• High precision: up to 32 bits per channel, HDR and wide gamut.
• Transparency and animation, like PNG and GIF.
• Progressive decoding: according to jpegxl.info, an image can start to appear with as little as 1% of the file loaded, then sharpen as the rest arrives.
• Lossless JPEG transcoding, which is the part I find most interesting.

Repack the JPEGs you already have

Most sites already have a folder full of JPEGs. Re-encoding them lossily into a new format means another generation of compression artefacts. JPEG XL has a better option: it can repack an existing JPEG without decoding it to pixels first, so nothing is lost. jpegxl.info puts the average saving at about 20%, and the original JPEG can be rebuilt bit for bit.

Point at the stack in the figure: it opens back to exactly the outline it started from. That's the promise of the transcode. With libjxl's command-line tools, it's two commands:

cjxl photo.jpg photo.jxl   # JPEG input is transcoded losslessly by default
djxl photo.jxl photo.jpg   # rebuilds the original JPEG

So the repack is reversible. You can keep the JXL as your master and still produce the exact JPEG for any browser that needs it.

Ship it today with <picture>

You don't need a feature check in JavaScript. The <picture> element already does format negotiation: the browser walks the <source> elements in order, takes the first one whose type it supports, and falls back to the <img> if none match.

<picture>
  <source type="image/jxl" srcset="photo.jxl">
  <img src="photo.jpg" alt="Harbour at dusk" width="1200" height="800">
</picture>

Chrome 155 picks the highlighted line and downloads only the .jxl. A browser without JPEG XL skips it and loads the JPEG. Nobody downloads both.

A few things that break this if you get them wrong:

• The type attribute is required. Without it, the browser can't tell it doesn't support the source and won't skip it.
• End with an <img>, and keep alt, width and height on it. The <img> is what actually renders; <source> only swaps its URL.
• Serve the right Content-Type. Your server or CDN has to send image/jxl for .jxl files.
• Keep the list short. MDN notes that 2 or 3 sources is typically all you need. If you also serve AVIF, list it as a second <source>.
• CSS backgrounds have no <picture>. For background-image, use image-set() with type() hints, or move the image into an <img>.

Who can see it

That's why the fallback isn't optional. A meaningful share of your visitors, especially on Android, will still get the JPEG.

JXL or AVIF?

The tempting reading is "JXL beats AVIF, switch everything". Google says the opposite: try both. Its own expectation is that JPEG XL helps most with high-fidelity or lossless compression of photographic images, and where fine-grained progressive decoding matters. For heavily compressed thumbnails, AVIF may well win. Encode a handful of your real images both ways at the same visual quality and compare the bytes.

On a client project I would ship it today, but only behind <picture>, with AVIF or JPEG as the fallback, so a browser without JXL never notices.

The short version

1. Chrome 155 decodes JPEG XL; Google claims 30–50% better compression than JPEG.
2. Existing JPEGs repack losslessly for about 20% on average, and convert back exactly.
3. Ship it with <picture>: a type="image/jxl" source first, your JPEG <img> last.
4. Safari's support is partial, Firefox turns it on in 158, Chrome for Android isn't there yet.
5. Test against AVIF before you commit.

Sources: Chrome for Developers, JPEG XL in Chrome · jpegxl.info · MDN, Image file type and format guide · caniuse, JPEG XL · Phoronix, Mozilla's plan for JPEG-XL in Firefox · drweb.de, JPEG XL in Chrome 155