JPEG XL in 2026: Back in Chrome, Still Not Ready for Your Website

Short answer: JPEG XL is the best image format you should not use on your website yet. It is technically excellent, it is genuinely back in Chrome, and zero browsers enable it by default — including Chrome 151, the current stable release.

TL;DR: JPEG XL (.jxl, ISO/IEC 18181) compresses better than AVIF and WebP and can shrink existing JPEGs by ~20% with bit-exact reversibility. But Can I Use puts it at 13.6% support, and every point of that is partial support in Safari. Chrome and Firefox ship it behind flags. Serve AVIF with a WebP or JPEG fallback instead.

This page exists because most of what is currently written about JPEG XL is wrong in the same direction: too optimistic. You will find articles claiming 20–25% browser support, or that Chrome enabling it by default is imminent, or quoting a specific H2-2026 ship date. None of those are supported by primary sources.

Here is what the actual documentation says.

What Is JPEG XL?

JPEG XL is a royalty-free image format standardised as ISO/IEC 18181, developed by the JPEG committee from two competing 2018 proposals: Google's PIK and Cloudinary's FUIF. The final format is, in Google's own words, a "best-of-both-worlds compromise" between them.

It uses the .jxl extension and the image/jxl MIME type. Per jpeg.org, it handles "lossy encoding, lossless encoding, and lossless recompression of existing JPEG images", plus "animation, alpha channels, layers, thumbnails, lossless and progressive coding" and "wide colour gamut as well as high dynamic range and high bit depth images".

That is an unusually broad feature list. JPEG XL is designed to replace JPEG, PNG, and GIF with one codec rather than sit alongside them, which is a different ambition from WebP or AVIF.

The reference implementation, libjxl, is BSD-licensed and free.

Why Is Lossless JPEG Recompression the Interesting Part?

Of everything JPEG XL does, this is the feature with a real-world business case today.

You can take an existing JPEG, recompress it as JPEG XL, and get a file roughly 20% smaller — then reconstruct the bit-exact original JPEG from it whenever you want. Not a visually identical JPEG. The same bytes.

This is worth trusting because two independent sources agree on it. Cloudinary reports files "on average about 20% smaller, without introducing any loss. In fact, the bit-exact same JPEG file can be reconstructed from the JPEG XL file." Apple's WebKit blog independently gives the same figure: "no loss of quality or data, while reducing their size by an average of 20%."

For an archive of millions of JPEGs, that is a 20% storage cut with a guaranteed undo. It is the strongest argument for JPEG XL that does not depend on browsers at all — and notably, it is a storage argument, not a delivery one.

What Is the Real Browser Support Picture?

This is where the format's story actually lives, and where most coverage goes wrong.

Source: Can I Use.

Two details matter more than the headline percentage.

Partial means genuinely partial. Can I Use is specific: Safari "supports still images. Animated image sequences are not supported", and "partial support refers to not supporting progressive decoding". So the one browser that ships JXL by default ships it without two of the format's headline features.

Nothing outside Safari counts. A flag that is off by default contributes zero real traffic. Chrome 151 is the current stable release and it will not decode a .jxl file for your visitors.

So the honest planning number is not 13.6%. Without a fallback, it is effectively Safari or nothing.

Why Did Chrome Remove JPEG XL?

Worth knowing, because it explains why the return is more cautious than it looks.

Chrome added JXL behind the enable-jxl flag in version 91. In October 2022 Google announced removal, and the code — 111 files, over 2,000 deletions — landed in December 2022. It shipped removed in Chrome 110.

Google's stated reasons, verbatim:

• "Experimental flags and code should not remain indefinitely"
• "There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL"
• "The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default"
• "By removing the flag and the code in M110, it reduces the maintenance burden"

That third point is the one that stung, and it is the one the format's supporters spent three years arguing against.

Why Did Chrome Bring It Back?

In November 2025, Rick Byers of the Chrome team posted a reversal. The exact wording matters, because it is more conditional than the headlines suggested:

"Since JPEG XL was last evaluated, Safari has shipped support and Firefox has updated their position... Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance."

Read that carefully. It is not a ship announcement. It is an invitation with two preconditions attached: a memory-safe decoder and a long-term maintenance commitment.

The work did happen. A pure-Rust decoder called jxl-rs was vendored into Chromium in December 2025, wired up in January 2026, and Chrome 145 shipped in February 2026 with the decoder present but gated behind a runtime flag. jxl-rs describes itself as "a work-in-progress reimplementation of a JPEG XL decoder in Rust".

So: real code, real progress, still off by default five stable releases later. Anyone quoting you a default-on date is guessing.

One correction worth making: Byers cited "Firefox has updated their position" as a reason to revisit. Mozilla's published standards position still reads neutral — "the benefits it provides are not significant enough on their own to justify the cost of adding another raster image format to the Web." The update was neutral-from-nothing, not an endorsement.

How Much Better Does JPEG XL Actually Compress?

Here is the part nobody wants to say out loud: the best JPEG XL benchmarks in existence were published by the company that co-created JPEG XL.

Cloudinary employs Jon Sneyers, who built FUIF and co-authored the JXL specification. Cloudinary's studies are careful, large, and use a metric (SSIMULACRA2) chosen specifically because no tested encoder optimises for it. They are also not neutral, and I could not find a vendor-independent large-scale benchmark to check them against.

With that disclosed, their subjective study — 250 images, over 40,000 test subjects, 1.4 million scores — reports JPEG XL achieving:

Their objective study adds a speed dimension that is arguably more interesting than the size numbers: at visually lossless quality, "libjxl is 20% smaller than libavif and 2.5 times as fast". At AVIF's slowest settings, AVIF "matches the compression density of the second-fastest libjxl setting, which is over 100 times as fast".

If those numbers hold up independently, JXL is a straightforward win. That "if" is doing real work, and you should treat anyone quoting these figures without naming the source as unreliable.

You will also see a claim that AVIF beats JPEG XL below roughly 0.4 bits per pixel. I could not verify it from any primary source, so it is not in this table. Cloudinary's data covers medium-to-visually-lossless quality, which is where web photography actually sits.

Which Image CDNs Support JPEG XL?

Very few. This is the practical wall you hit even if you decide you want JXL.

Three providers out of nine, and two of them will actually pick JXL for you. Fastly is the surprise: its format=auto "intelligently chooses the best format to deliver to the user prioritizing: JPEGXL, AVIF, WebP" — JPEG XL sits first in that list, ahead of AVIF. The catch is that JXL and AVIF encoding both require Image Optimizer Professional. The best image CDNs comparison has the full format matrix.

A trap worth naming: imgix's format parameter accepts jxr. That is JPEG XR, a long-dead Microsoft format, not JPEG XL. Several published comparison tables list imgix as supporting JPEG XL because someone misread three letters. It does not.

Can You Serve JPEG XL Today?

Technically yes. Practically, almost never worth it.

Safari does advertise image/jxl in its Accept header, so content negotiation is possible in principle. Almost no CDN acts on it.

The reliable approach is the <picture> element, which needs no CDN cooperation at all:

<picture>
  <source srcset="photo.jxl" type="image/jxl">
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description">
</picture>

Browsers skip any <source> whose type they cannot decode and fall through. Safari takes the JXL, everyone else drops to AVIF or WebP.

This works. It also means generating and storing an extra derivative for roughly 14% of your visitors, using a format seven of the nine major image CDNs cannot even produce. The responsive serving patterns guide covers the same technique for formats that are actually worth the storage.

What About Tooling?

The reference tools are solid. cjxl and djxl ship in libjxl (brew install jpeg-xl, apt install libjxl-tools), handle PNG/JPEG/GIF/APNG/EXR input, and default to lossless JPEG round-tripping. ImageMagick supports JXL read/write with the delegate library installed.

Node pipelines are where it falls apart. sharp's own documentation is unusually blunt about .jxl():

"This feature is experimental, please do not use in production systems."

It also notes that "the prebuilt binaries do not include" libjxl support — so npm install sharp cannot produce JXL at all. You would have to compile libvips against libjxl yourself, against the maintainer's explicit advice.

One more signal worth reading: libjxl v0.12.0, released in July 2026, carries a note that updating is "highly recommended... due to numerous security fixes." That is not a scandal — it is a young codec maturing — but it does explain precisely why Chrome insisted on a memory-safe Rust decoder before considering shipping.

So Should You Use JPEG XL?

On a public website: no. Not as your only format, and the fallback cost is not worth it for Safari-only coverage. Serve AVIF first, WebP second, JPEG as the floor. That recommendation has not changed and JXL's return to Chrome does not change it.

For archival storage: genuinely yes, if it fits. The 20% lossless JPEG recompression with bit-exact reconstruction is real, corroborated by two independent sources, and needs no browser support whatsoever. If you are sitting on a large JPEG archive, this is the use case the format has already won. The lossless image formats guide covers where it fits among the alternatives.

For experiments: sure. Use <picture> with fallbacks, expect Safari-only pickup, and do not let it into a build pipeline you depend on.

The thing to watch is not a percentage. It is whether someone commits to long-term maintenance of jxl-rs, because that is the condition Chrome actually named.

Summing Up!

JPEG XL is a better codec than the ones we use. It is also a format that zero browsers turn on by default, that seven of nine major image CDNs cannot generate, and whose flagship benchmarks were produced by one of its own authors. All three of those things are true at once, and most coverage picks only the flattering one.

For your website, nothing has changed: serve AVIF, fall back to WebP, keep JPEG as the floor. The format decision guide covers the full map, and any decent image CDN will negotiate those formats for you automatically — which is precisely what JXL still cannot get.

For your archive, JPEG XL is already worth it today. A 20% cut with a bit-exact undo button is a real, boring, useful win that no browser vote can take away.

Watch for one thing only: someone committing to long-term maintenance of the Rust decoder. Chrome named that as its condition. Until it happens, JPEG XL stays a great format you cannot ship.