Should I switch my whole site from AVIF to JPEG XL?

Not yet. For typical, heavily compressed web images AVIF has far wider support. Chrome's own post recommends trying both and says JPEG XL helps most with high-fidelity or lossless images.

Do I really get the original JPEG back after converting?

Yes. cjxl recompresses JPEG input losslessly by default, and djxl writing a .jpg reconstructs the original file. Check with cmp that every byte matches.

Can I use Accept-header content negotiation instead?

You can, but it is fiddlier. Firefox 158 now sends image/jxl in its image Accept header, but you need Vary: Accept and a CDN that caches per variant correctly. For most sites picture with type is simpler and harder to get wrong.

JPEG XL is back in Chrome: why it was removed and should you use it now

JPEG XL is an image format standardised as ISO/IEC 18181. It compresses better than JPEG, supports HDR, animation and progressive decoding, and can losslessly re-encode existing JPEG files. Chrome removed it in 2022 and many people assumed that was the end. In October 2026 Chrome brought it back. Here is what happened, who supports it now, and how far to go with it.

Facts checked against the Chrome for Developers blog, caniuse, MDN (Firefox 158) and the libjxl 0.12 README as of October 2026.

Why Chrome removed it

Chrome carried a JPEG XL decoder behind a flag from Chrome 91 (you had to turn it on in chrome://flags; ordinary users never saw it). At the end of October 2022 the Chromium team announced its removal in Chrome 110, giving three reasons on the bug tracker:

Experimental flags and code should not stay around forever
There was not enough interest from the entire ecosystem to keep experimenting
It did not bring enough incremental benefit over existing formats (AVIF and WebP) to enable by default, and removing it cut maintenance work

Chrome 110 reached stable on 7 February 2023 without JPEG XL. Many developers objected, but with the largest browser out, most sites had no reason to produce .jxl files.

Four years from removal to return, now with a Rust decoder

Why it came back, and what jxl-rs is

Chrome’s post (6 October 2026) says the decision followed consistent feedback and requests from web developers. JPEG XL was a popular proposal for Interop 2026, and Chrome joined the Interop 2026 JPEG XL investigation to build test coverage for the format’s features.

The more interesting part is the decoder. Chrome did not bring back libjxl (C++). It uses jxl-rs, a pure Rust decoder. Image decoders are a favourite target: they parse a complex format from any website on earth, and memory bugs in C/C++ decoders have become serious browser vulnerabilities more than once. Rust rules out that class of bug at the language level. The Chrome team says it used fuzzing and AI code review and has found no memory-safety bugs across the implementation’s history.

This is more than format news. It is a clear example that code parsing data from strangers belongs in a memory-safe language.

Who supports it, as of October 2026

Browser	Status
Chrome desktop	155+ (stable 6 Oct 2026)
Chrome Android	156+
Firefox (desktop and Android)	158+, on by default (13 Oct 2026)
Safari macOS / iOS	17+, marked partial on caniuse
Edge	not supported
Samsung Internet	not supported

caniuse puts global users at 43.26% full support plus 16.93% partial, 60.19% in total, against roughly 96% for AVIF (covered in responsive images with AVIF and WebP). The JPEG XL figure should climb quickly, since Chrome and Firefox update themselves.

Firefox 158 also added image/jxl to the Accept header for image requests. The new value is image/avif,image/jxl,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5.

Where JPEG XL beats AVIF

Chrome’s post cites 30-50% better compression than JPEG, recommends trying both AVIF and JPEG XL, and says JPEG XL helps most with high-fidelity or lossless compression.

	AVIF	JPEG XL
Support (caniuse, Oct 2026)	~96%	~60% (incl. partial)
Typical web photos, heavy compression	strong	fine
High fidelity / lossless	fine	strength
Lossless re-encoding of existing JPEGs	no	yes, round-trips to the original
Progressive (coarse image first)	limited	fine-grained
HDR	yes	yes

The thing no other format offers is lossless JPEG transcoding. A site with tens of thousands of old JPEGs can convert them to smaller .jxl files with not one pixel changed, and get the exact original JPEG back whenever it wants.

Try it on your own images

Install libjxl. Debian and Ubuntu ship libjxl-tools, but the repo version may be old; libjxl recommends 0.12 or later because of numerous security fixes.

# Debian 13 / Ubuntu
sudo apt install libjxl-tools

# Existing JPEG -> JPEG XL, lossless (cjxl's default for JPEG input)
cjxl photo.jpg photo.jxl

# Convert back and check it matches the original byte for byte
djxl photo.jxl back.jpg
cmp photo.jpg back.jpg && echo "identical"

# From a PNG master: lossy with distance (0 = lossless, useful range 0.5-3)
cjxl hero.png hero.jxl -d 1.0
ls -l photo.jpg photo.jxl hero.png hero.jxl

How much you save depends on the images, so we give no single figure. Run it on 20-30 real files and look at the totals.

Adding it to a page with picture

The browser reads <source> elements top to bottom and skips any type it does not know, so adding JPEG XL breaks nobody.

<picture>
  <source type="image/jxl"  srcset="/img/product-800.jxl 800w, /img/product-1600.jxl 1600w"
          sizes="(min-width: 800px) 800px, 100vw">
  <source type="image/avif" srcset="/img/product-800.avif 800w, /img/product-1600.avif 1600w"
          sizes="(min-width: 800px) 800px, 100vw">
  <img src="/img/product-800.jpg" alt="Brown leather bag, front view"
       width="800" height="800" loading="lazy">
</picture>

Order: for high-fidelity images (zoomable product shots, photography) put JPEG XL first. For ordinary, heavily compressed images, AVIF first and no JPEG XL at all is a perfectly good answer.

Worked example: the cost of a third format

Say each image is produced at 4 widths (480, 800, 1200, 1600).

Today, AVIF + JPEG = 4 × 2 = 8 files per image
Add JPEG XL = 4 × 3 = 12 files per image, an increase of (12 − 8) ÷ 8 = 50%
A library of 2,000 images goes from 16,000 to 24,000 files; build time and storage/CDN footprint grow roughly in proportion

Now the return, with made-up numbers to show the method (swap in what you measured above). Suppose a product image is 120 KB as AVIF and 100 KB as JPEG XL. A visitor who gets JPEG XL saves 20 KB per image; a product page has 10 images, so 200 KB per page. With 60% of visitors supporting JPEG XL and 50,000 page views a month:

50,000 × 0.60 × 200 KB = 6,000,000 KB ≈ 6 GB a month

If 6 GB a month is worth 50% more files, do it. If your measured difference is much smaller, stay with AVIF for now.

Common mistakes

Serving .jxl straight from <img>. Edge and older browsers show a broken image. Always wrap it in <picture> with a fallback
Wrong Content-Type. An older nginx mime.types may lack jxl. Check with curl -sI https://example.com/img/a.jxl for image/jxl; if missing, add image/jxl jxl; to types
Accept negotiation without Vary: Accept. The CDN caches the .jxl and hands it to browsers that cannot open it
Lossy re-compressing JPEGs. If the source is already JPEG, use the lossless transcode (the default); lossy on top of lossy loses quality twice
An old libjxl on a server that processes user uploads. Older versions have vulnerabilities fixed in 0.12

You can use JPEG XL today inside a picture with fallbacks. AVIF remains the workhorse for ordinary web images.

Sources

Commands and settings were tested on sample systems. Try them on a test machine before production.