JPEG XL Is Becoming a Practical Choice for the Web

Joshua Morris · Joshua Morris ·

8 min read Original article ↗

JPEG XL interests me because it addresses something I care about when building a website: sharing good photographs without making the page unnecessarily heavy. It supports both lossy and lossless compression, progressive loading and a way to reduce the size of existing JPEGs while keeping the originals recoverable. Safari, Chrome and Firefox now support the format, giving more people a browser that can display it. That makes this a useful time to look at what JPEG XL offers, how the browsers handle it and where the limitations remain. jpeg.org

Updated November 10, 2026: after this note was on Hacker News, a reader pointed me at Jake Archibald’s JPEG XL versus AVIF compare (discussion). That piece is how jixel entered the story for me: a newer lossy JPEG XL encoder that often produces smaller files than libjxl’s cjxl at similar settings. I re-ran the same three photographs with jixel, kept the original cjxl table as a historical run, and switched this site’s live display encodes to jixel.

Which browsers support JPEG XL?

Support varies by browser, platform and feature. A still image can work even when animation does not. An experimental flag also differs from something enabled for every visitor. This is the documented position as of November 6, 2026.

BrowserSupportWhat that means
Chrome on desktop and AndroidEnabled by default from version 155Native decoding, including progressive rendering and animation. developer.chrome.com
Firefox on desktop and AndroidEnabled by default from version 158Native decoding, including progressive rendering and animation. MDN
Safari on MacSupported from Safari 17Still images work, but JPEG XL animation and progressive loading are not supported. WebKit
Safari on iPhone and iPadSupported from iOS 17 and iPadOS 17The same still-image support and limitations apply. WebKit

Other Chromium browsers are adopting the format on their own schedules. An independent test of Brave 1.97.57 on Windows found native decoding enabled and confirmed that <picture> selected the JPEG XL source. Users have also reported support in Opera 139 and Vivaldi 8.3 on desktop and mobile. Those are useful firsthand reports, but I would verify the particular build and features before treating them as a complete compatibility guarantee. jpegxlconvert.com

Several smaller browsers support JPEG XL too. Waterfox documents built-in decoding, with version 6.7.7 adding automatic use of multiple processor cores. Pale Moon enabled support unconditionally in version 33.8.0, while Basilisk added progressive decoding and animation in its January 2023 releases. Thorium maintained its own integration of the libjxl decoder after upstream Chromium removed the earlier implementation. The JPEG XL community’s compatibility list also names Orion, Zen and Ladybird, although it does not establish a minimum version or feature coverage for each. jpegxl.info

On iPhones and iPads, browsers using Apple’s WebKit follow the system’s image support, including Safari’s progressive loading and animation limitations. Edge on desktop is a separate case: The current Web Features Explorer and MDN compatibility data still list it as unsupported. I would keep those visitors on a fallback. Sharing an engine with another browser does not guarantee identical support. MDN

What JPEG XL brings to a photograph

The JPEG Committee’s overview describes a format built for both web delivery and photography. Alongside lossy and lossless compression, JPEG XL supports transparency, animation, wide color gamuts and high dynamic range, or HDR. Those capabilities give publishers options for preserving more of an image’s detail and color. How much they help depends on the source image, encoding settings and software displaying the result. The two features that interest me most are progressive loading and reversible compression of existing JPEGs. jpeg.org

Matching crops from JPEG, WebP, AVIF and JPEG XL at comparable SSIMULACRA2 scores.Credit: Photograph by Jim Peaco, Yellowstone National Park, public domain.

Progressive loading lets a compatible browser show an initial version of an image and refine it as more data arrives. Mozilla’s sleeping fox demonstration makes the idea easy to see: The subject becomes recognizable before the full photograph has downloaded. On a slower connection, that can give someone something useful to look at while the remaining detail arrives. The image has to be encoded for progressive delivery, and the browser has to implement it. Safari’s ability to display a completed JPEG XL file does not currently include that loading behavior. hacks.mozilla.org

Reversible JPEG compression is useful for a different reason. JPEG XL can store an existing JPEG more efficiently while retaining the information needed to reconstruct the original file exactly. In the archival Yellowstone example, the file went from 2,709.1 KiB to 2,087.1 KiB, a reduction of about 23%, and converting it back produced the same SHA-256 hash. That preserves what was already in the JPEG; it cannot recover detail discarded when the original was compressed. I find the ability to recover the original file particularly appealing for photographs I want to keep. jpeg.org

AVIF produced the smaller file for the Chrysler Building photograph at the comparison’s target score. Matching crops make the architectural detail easier to inspect.Credit: Photograph by Samuel Gottscho, Library of Congress, public domain.

What the image comparison shows

The first table is the historical run from when this note published. Those three photographs were resized to a 1,600-pixel long edge. JPEG XL was encoded with libjxl’s cjxl -d 1 -e 7, and JPEG, WebP and AVIF were adjusted to within 0.75 of its SSIMULACRA2 perceptual quality score, around 87. That provides a comparable target, although a score cannot tell us whether every detail looks equally good. The sizes describe the complete encoded photographs, while the accompanying crops show matching details.

In that cjxl run, JPEG XL produced the smallest files for the landscape and portrait, while AVIF produced the smallest file for the Chrysler Building. Three photographs give us examples to inspect, but they do not establish a winner for every image on a website. I would compare representative photographs at the quality I actually want to publish, then inspect textures, gradients and edges before choosing a format. The useful result is finding a better way to deliver those particular images.

I then encoded the same masters again with jixel-cjxl -d 1 -e 7, which is the wrapper this site now uses for display JPEG XL. At those identical distance and effort flags, jixel produced smaller JPEG XL files on every photograph. Its SSIMULACRA2 scores landed a few points lower than the earlier cjxl run, so the encoder comparison below is a same-settings measurement rather than a claim of identical perceptual quality. The file-size gap is still the reason I changed the publishing pipeline.

With jixel as the JPEG XL reference, I retargeted JPEG, WebP and AVIF to within 0.75 of its SSIMULACRA2 score and refreshed the four-format table. JPEG XL remained the smallest file for the landscape and the portrait. AVIF remained smaller than JPEG XL for the Chrysler Building at that target. The crop boards above use this refreshed encode set, so their labels match the jixel-anchored sizes rather than the historical cjxl table.

Putting it on a website

The HTML needed to offer JPEG XL is straightforward. A <picture> element can provide a JPEG XL source, an AVIF alternative and a JPEG fallback. The browser selects a source it supports, so visitors can receive an appropriate image without changing their settings. This example gives JPEG XL priority, followed by AVIF and then the JPEG in the <img> element. MDN

<picture>
  <source srcset="/images/landscape.jxl" type="image/jxl" />
  <source srcset="/images/landscape.avif" type="image/avif" />
  <img
    src="/images/landscape.jpg"
    alt="A forest and mountain reflected in a still lake"
    width="1200"
    height="800"
  />
</picture>

The order matters because the browser does not download every version and choose the smallest file. Put the format that works best for that image first, generate the alternatives and serve JPEG XL with the image/jxl content type. Keep the dimensions and alternative text accurate, then check which file the browser actually requests. A fallback handles unsupported formats; it is not an automatic recovery mechanism for a missing or broken preferred image. MDN

For a photography page or an illustrated article, I would start with a small set of images and compare the result in the browsers people actually use. Images that look right and deliver a useful saving can earn a place in the publishing process. The fallback stays in place for everyone else. Broader browser support makes that a practical way to try JPEG XL while keeping the page available to the people who came to read it.

Sources and examples