JPEG XL Chrome Support Explained: When to Use It Over AVIF or WebP

Images break, lose quality or end up bigger than they need to be when a team swaps every file to a new format in one go. JPEG XL Chrome support arrived in Chrome 155 on 6 October 2026, and that news tempts teams to convert everything to .jxl overnight.

A browser that cannot decode the new format shows a broken image unless the page offers another version. Turning a JPEG back into pixels and saving them as a new lossy file adds a second round of quality loss. And for screenshots and banners with text, AVIF often makes smaller files.

Picture a common setup. An online jewellery shop holds 40,000 product photos saved as JPEGs years ago, and most original camera files are gone. Its CDN (content delivery network, the servers that deliver files from near each visitor) bill is about ₹70,000 a month. The setup is made up, but the problem is real.

A frontend engineer on the team reads the Chrome 155 news and proposes converting the whole catalogue that weekend. The team lead asks for one page first: what to convert, what to skip and what other visitors will see. This guide builds that page.

• Decoder: the code that unpacks an image file into pixels. A browser needs one for each format it shows.
• Encoder: the tool that writes the file. Its effort setting is how long it searches for a smaller file.
• Transcode vs re-encode: transcoding repacks a JPEG's existing data; re-encoding decodes to pixels and compresses them again, losing more detail.
• Progressive decoding: showing a rough image while the rest of the file still downloads.
• MIME type: the label naming a file's format, such as image/jxl, image/avif or image/webp. Servers send it in the content-type header.

Yes. Chrome 155 decodes .jxl images without a flag (a hidden setting you switch on by hand), and version 155 reached stable on 6 October 2026. Chrome's 155 release notes describe decoding for image/jxl using jxl-rs.

The Intent to Ship, Chrome's public notice that a feature is ready, was posted on blink-dev, Chrome's public developer mailing list, on 24 August 2026. Its rollout plan says the feature will ship enabled for all users. It got three LGTM ("looks good to me") approvals that day.

The same notice names a Finch feature, JXLImageFormat. Finch is the system Chrome uses to switch features on or off from a server, and Chrome's docs say it can remotely disable problematic features. So treat "enabled for all users" as the plan, not a guarantee.

The Chrome team's launch post says JPEG XL offers "30-50% better compression than JPEG". That is the team's claim, not a figure this guide tested. It also lists lossless compression, HDR (high dynamic range: brighter highlights and deeper shadows) and lossless JPEG transcoding.

Chrome tried JPEG XL once before, behind a feature flag that was off by default, then removed it. That attempt began with a blink-dev Intent to Prototype, Chrome's notice that work on a feature is starting, on 30 March 2021.

On 11 November 2022, Chrome announced it would "stop Chrome's JPEG XL experiment and remove the code". The post listed questions such as compression across many images, decoder speed, encoding cost and support in other browsers and operating systems.

The 2026 launch post says the decision to ship was based on consistent feedback and requests from web developers. JPEG XL was a popular proposal in the Interop process, the yearly effort where browser makers pick features to make work alike, in 2026 and several years before.

JPEG XL can losslessly transcode an existing JPEG: it stores the JPEG's image data more compactly in a .jxl file, plus reconstruction data. Nothing new is thrown away, and MDN notes that the original JPEG file can be reconstructed.

Think of repacking a suitcase: the same clothes come out, they just take less space. Re-encoding is different. Decoding a JPEG to pixels and saving them as a new lossy file loses detail again, like photocopying a photocopy.

Where the picture breaks: anyone can open a suitcase, but only software with a JPEG XL decoder can open a .jxl. That is why the original JPEG stays on the server as the fallback.

Jake Archibald's tests found lossless transcoding made JPEGs 9 to 20 percent smaller. The saving grew with image width, from about 9 percent at 400 pixels wide to about 20 percent at 4,900 pixels.

The engineer estimates the monthly saving. Every input except the 9 to 20 percent range is made up, and GB here means decimal gigabytes (1,000,000 kB).

avg_jpeg_kb = 380                # made up: average archive photo, in kB
monthly_downloads = 30_000_000   # made up: image downloads per month
jxl_share = 0.6                  # made up: share of downloads from browsers that pick the .jxl
rupees_per_gb = 6                # made up: CDN price per GB

for saving in (0.09, 0.20):      # range from Jake Archibald's JPEG transcoding tests
    gb_saved = monthly_downloads * jxl_share * avg_jpeg_kb * saving / 1_000_000
    rupees = gb_saved * rupees_per_gb
    print(f"{saving:.0%} smaller: {gb_saved:,.0f} GB and about Rs {rupees:,.0f} saved a month")

The script prints 616 GB and about Rs 3,694 (Rs means rupees) at 9 percent, and 1,368 GB and about Rs 8,208 at 20 percent (made up). Useful, but only a modest slice of a ₹70,000 bill, and the engineer says so.

Pause and predict: if JPEG XL repacks old JPEGs this well, will it also make the smallest new lossy photos? The next table answers with measurements.

For most new lossy images, Jake Archibald's October 2026 tests favour AVIF. JPEG XL won for lossless images and old JPEGs. WebP stays a widely supported fallback; MDN says major browsers broadly support it.

His default is "AVIF 4:4:4, with the highest effort level I can be bothered with". Here 4:4:4 means full colour detail is kept rather than shared between neighbouring pixels.

The Chrome team says to try both AVIF and JPEG XL. It expects JPEG XL to help most with high-fidelity or lossless compression, especially of photographs.

Lossless gaps depend on the images. On four sample photos with libjxl 0.12.0, our lossless WebP files were 0 to 8 percent larger than JPEG XL, a smaller gap than his.

Jake also found JPEG XL typically takes 2 to 3 times as long as AVIF to decode at medium quality. The gap narrowed at very high quality.

The engineer turns the table into a rule for the upload pipeline, returning picture sources best first.

def pick_sources(photo):
    """Return the picture sources for one image, best first."""
    if photo["origin"] == "old_jpeg":
        # Lossless repack: same JPEG data, smaller file, original JPEG as fallback
        return ["jxl", "jpeg"]
    if photo["needs_exact_pixels"]:
        return ["jxl", "webp", "png"]
    # New lossy photos, banners and cut-outs: AVIF first, as public tests suggest
    return ["avif", "webp", "jpeg"]


catalogue = [
    {"name": "jhumka_0412", "origin": "old_jpeg", "needs_exact_pixels": False},
    {"name": "hallmark_scan", "origin": "scanner", "needs_exact_pixels": True},
    {"name": "diwali_banner", "origin": "design", "needs_exact_pixels": False},
]
for photo in catalogue:
    print(photo["name"], "->", pick_sources(photo))

It prints jxl then jpeg for the old jhumka (earring) photo, jxl, webp and png for the hallmark scan, and avif, webp and jpeg for the banner. The team keeps lossless rare, since Jake found lossy AVIF handles screenshots well.

Put each format in its own source line inside a picture element, best first, and end with a plain img tag. MDN says a browser compares each source's MIME type with the types it can display, and skips unsupported ones without asking the server.

MDN advises giving JPEG XL an alternative such as AVIF, WebP or JPEG. As of 19 October 2026, MDN lists Chrome 155, Firefox 158 and Safari 17, but still calls support not yet universal.

So what will other visitors see? Shoppers on current Chrome, Firefox and Safari get the .jxl. Older versions, and browsers such as Samsung Internet that caniuse marks unsupported, get the JPEG.

The order of sources

Order sets priority. For repacked archive photos, the team lists the .jxl source first and keeps the original JPEG in the img tag. For new lossy photos it lists AVIF, then WebP, then JPEG.

Rolling out without surprises

• Start with one category, such as earrings, and compare load times.
• Check that your CDN sends .jxl files with the image/jxl content type, using the command below.
• Keep the original JPEGs: they are your fallback and your undo button.
• Watch real-user timings on low-end Android phones.

curl -sI "$IMAGE_URL" | grep -i content-type
# expected: content-type: image/jxl

Set IMAGE_URL to one of your .jxl files. The header name's capitalisation can vary. If the value shows something else, such as application/octet-stream, fix the server's type mapping before rollout.

If you are new to image formats, you can stop here. The sections below are for engineers who will run the conversion and own its cost.

Rebuild the JPEG from the .jxl and compare the two files byte for byte. cjxl is the JPEG XL encoder and djxl the decoder from libjxl, the reference library.

cjxl photo.jpg photo.jxl          # JPEG input: lossless transcode by default
djxl photo.jxl restored.jpg       # .jpg output: rebuild the original file
ls -l photo.jpg photo.jxl restored.jpg
cmp photo.jpg restored.jpg && echo identical

What just happened? In version 0.7.0, cjxl's log says "lossless transcode" and "JPEG reconstruction data". ls should show photo.jpg and restored.jpg with the same size in bytes. cmp prints nothing when the files match, so the last line is identical.

We ran these commands with cjxl and djxl 0.7.0, the Ubuntu 24.04 package. The 0.11.2 manual pages document the same defaults: JPEG input is transcoded losslessly, and a .jpg output rebuilds the exact original.

What we measured with libjxl 0.12.0

Using libjxl 0.12.0, the version Jake tested, we transcoded 39 JPEGs made from sample photos 451 to 1,411 pixels wide. Every one came back byte-identical. Savings ran from 8 to 18 percent.

How the JPEG was saved mattered most. Already-optimised progressive JPEGs (saved to load in passes, with tuned compression tables) saved only 8 to 11 percent, and less at higher JPEG quality. The other JPEGs, including three sample files used as shipped, saved 11 to 18 percent.

The pixel trap

A .jxl made from pixels cannot give the original JPEG back. In our 0.7.0 test, djxl wrote a brand-new JPEG instead: 102,615 bytes against the original 56,809, and not identical.

Displayed pixels can also differ slightly even after a true transcode. We decoded the same photo with libjxl and with libjpeg-turbo, a common JPEG decoder. The results differed by under one level out of 255 on average, and by up to 22 at single points. The file is identical; the decoders' maths differs slightly.

jxl-rs is a JPEG XL decoder written in Rust, a language whose safe subset rules out whole classes of memory bugs. Chrome's post calls image decoders "one of the most critical and targeted attack surfaces" in a modern browser.

A decoder reads bytes from any website, including hostile ones. Chrome's post says decoders written in memory-unsafe languages like C++ have been prone to out-of-bounds reads, heap overflows and use-after-free bugs.

Safe Rust refuses to compile code that keeps a reference to memory after it is freed. It also stops the program, instead of reading stray memory, when code indexes past the end of an array.

The post says decoders run inside the renderer process, the part of Chrome that builds web pages, and calls sandboxing a secondary layer of defence. The sandbox is a walled-off process with few rights; memory-safe code is meant to stop the bug first.

For speed, the decoder uses SIMD instructions, which handle many pixels in one step. A Rust feature, target_feature_11, had to be stabilised so SIMD could be used without unsafe code, Rust's escape hatch from its checks.

The remaining unsafe operations sit in a SIMD layer called jxl_simd, restricted to what the post calls a small number of highly vetted locations. So when Chrome's release notes call jxl-rs a "memory-safe pure Rust decoder", that does not mean zero unsafe code.

The team checked the decoder with fuzzing, which feeds it huge numbers of broken files, and with AI review of the code. The post says it has "not found any memory safety bugs throughout the entire implementation history".

In Chrome, both can show a preview before the file finishes, but in Jake Archibald's test AVIF's early preview was more useful. The Chrome team still highlights JPEG XL for cases where fine-grained progressive decoding is preferred.

Jake found progressive JPEG XL "basically free at high effort" in file size. On one large photo, JPEG XL showed a very blurry preview after about 2 kB.

AVIF showed a recognisable preview after about 11.5 kB, and JPEG XL needed about 63 kB to match it. He worries a blurry preview can look like a finished but poor image.

As of his 15 October 2026 post, only Chrome supports progressive AVIF, and Chrome and Firefox show progressive JPEG XL. Safari shows a .jxl only once it has fully downloaded, as MDN also notes. The shop's zoom photos often load on patchy mobile data. So the team will test both formats in Chrome and in Safari on an iPhone, on a connection slowed on purpose.

More than lossless WebP, by a wide margin in some measurements. This was the main worry raised in the Intent to Ship thread before launch.

One participant measured lossless JPEG XL decoding about 15 to 20 times slower than lossless WebP, single-threaded, on a very large test image. He worried about battery, and noted cached images pay that cost on every page view.

Luca Versari, a co-author of Chrome's launch post, replied that the encoder's faster decoding setting "doubles decoding speed" without much change in size. He added that the huge test image would decode faster on several threads.

Philip Jägenstedt, another co-author of the post, called it a real risk but expected adoption to ramp up slowly. Our own run agrees on the direction. With libjxl 0.12.0 on one thread, lossless JPEG XL took 10 to 16 times as long as lossless WebP on two sample photos, 512 and 741 pixels wide. Faster decoding level 1 cut decode time by about a third, less than the doubling claimed, for 1 to 2 percent more bytes. Timings varied between runs.

Treat those as libjxl numbers, not Chrome numbers, because Chrome 155 decodes with jxl-rs. Transcoded JPEGs look different: Jake measured them slower than JPEG on small images, matching from about 1,000 pixels wide, and faster in Chrome at the largest sizes.

Treat it as a trade-off about formats, fallbacks and cost, using the jewellery shop as your example.

1. 1

   State the goal

   Say what you optimise: bytes sent, time to a preview, quality or decode cost on cheap phones.

2. 2

   Split images by kind

   Separate old JPEGs, new lossy photos, graphics and lossless assets.

3. 3

   Pick formats with evidence

   Cite public tests: AVIF often wins lossy, JPEG XL wins lossless and JPEG repacking. Say you would test your own images.

4. 4

   Design the fallback chain

   Use a picture element, best format first, with a JPEG or PNG img tag last.

5. 5

   Plan the pipeline

   Encode in a background worker at upload, store variants in object storage, serve through the CDN with the right content type.

6. 6

   Measure and roll back

   Roll out per category, watch real-user decode timings and keep originals to switch back.