Developers, marketers, and founders use Allscreenshots to automate website captures. No credit card required to get started.
Saving an image as .jxl is easy once you have an encoder. Making sure every visitor sees it takes a little more work.
JPEG XL can be a useful extra format in an image pipeline. It should earn that place through measured results and a working fallback, rather than a blanket assumption that the newest browser on your laptop represents everyone.
Here is a small, deployable pattern, using a real screenshot and files you can inspect.
We captured WebKit's Safari 17 announcement at 1280 × 800 on 29 September 2026. The page has text, colored links, flat backgrounds, and an embedded image, which makes it a useful UI-style test.
The same opaque, 8-bit sRGB capture was encoded into five formats. PNG was lossless; the other rows use each encoder's quality 80. JPEG and AVIF used 4:4:4 chroma; WebP and AVIF used effort 6; JPEG XL used effort 7.
| Encoding | Size | Encode time | SSIMULACRA 2 |
|---|---|---|---|
| PNG, level 9 | 187.9 KiB | 47.8 ms | 100.0 |
| JPEG, q80 / 4:4:4 | 124.9 KiB | 7.9 ms | 80.7 |
| WebP, q80 / effort 6 | 69.2 KiB | 84.1 ms | 79.0 |
| AVIF, q80 / effort 6 | 73.5 KiB | 775.3 ms | 89.2 |
| JPEG XL, q80 / effort 7 | 86.8 KiB | 200.4 ms | 83.6 |
JPEG XL was smaller than JPEG in this sample, but larger than the WebP and AVIF files. Their measured quality scores differ, so this is not an equal-quality ranking. JPEG XL's SSIMULACRA 2 score was 83.6; AVIF's was 89.2; WebP's was 79.0.
The strips above show the reference, the decoded JPEG XL, and the decoded AVIF, enlarged three times and stored as PNG. They let every reader inspect the result even if their browser cannot display the original JXL. They are not screenshots of a browser's JPEG XL decoder.
Download the originals: PNG · JPEG · WebP · AVIF · JPEG XL.
This compatibility check was made on 29 September 2026. It is deliberately a dated snapshot because the rollout is moving.
| Browser family | What the vendor evidence establishes |
|---|---|
| Safari | WebKit announced JPEG XL support in Safari 17, with OS requirements listed in its release post. |
| Chrome / Chromium | Chrome 145 documented a flag-gated decoder. Chromium published an intent to ship in August 2026; do not read the 145 entry as default support for all users. |
| Firefox | Mozilla's shipping discussion revised the default-on target from 157 to 158. Earlier builds may expose a preference or Labs option. |
| Other browsers and embedded viewers | Verify the specific release and platform; an engine announcement is not a test of every app using it. |
Sources: Safari 17 release notes, Chrome 145 release notes, Chromium's shipping discussion, and Mozilla's revised shipping target.
A target version is not proof that a rollout completed. The fallback below remains useful after more browsers enable the format, because older installations, embedded clients, and downstream tools remain in use.
<picture>
<source srcset="/images/capture.jxl" type="image/jxl">
<source srcset="/images/capture.avif" type="image/avif">
<source srcset="/images/capture.webp" type="image/webp">
<img src="/images/capture.png"
width="1280" height="800"
alt="The WebKit Safari release announcement">
</picture>The browser considers the sources in order. A browser that supports JPEG XL can use the first source; another can move on to AVIF or WebP. PNG is the final fallback. The img element still supplies the alt text and dimensions. MDN documents the source-selection rules.
Order is a policy choice. This example prioritizes JPEG XL so you can test it. Our measured AVIF was smaller and had a higher metric score on this particular capture, so the benchmark does not justify preferring JXL for this asset automatically.
Also, picture is a format-selection mechanism, not general error recovery. A supported source that returns a 404 or corrupt bytes can still produce a broken image. Check every file URL.
Use distinct URLs for distinct encodings:
| Extension | Content type |
|---|---|
.jxl | image/jxl |
.avif | image/avif |
.webp | image/webp |
.png | image/png |
.jpg | image/jpeg |
That makes it easier to inspect requests and avoids mixing several representations under one cache key. If you instead negotiate formats at one URL, configure your cache to distinguish the negotiated representations. Do not let a response prepared for one client become an incompatible cached response for another.
You can see the selected source in the browser console:
const image = document.querySelector('picture img');
await image.decode();
console.log(image.currentSrc, image.naturalWidth, image.naturalHeight);Run that against an actual deployed page. A successful server-side djxl decode proves that one decoder can read the file; it does not test your CDN headers, browser support, or source markup.
Use a browser with default settings that supports the new source, and a client that takes a fallback. Inspect the selected URL, visible image, and dimensions. Check that the page still makes sense when images are disabled and the alt text is all that remains.
Then test the destinations outside your website. A user may download an image, paste it into a ticket, or attach it to a document. A sensible website policy can still offer “download PNG” for that workflow.
For automated captures, keep a source master and generate the optional JXL derivative separately. The AllScreenshots capture in this experiment was PNG; we created JXL locally with cjxl.
JPEG XL supports progressive coding, but a viewer's behavior depends on both the file and the implementation. Mozilla specifically noted differences from Safari's implementation in its JPEG XL announcement.
Our conversion took roughly 200 ms for JPEG XL, versus 84 ms for WebP and 775 ms for AVIF. Those are median local conversion times, including file writes and, for JXL, process startup and PNG decoding. They do not measure progressive display, network loading, or browser decoding. The report includes the exact method and versions.
Ship the format when its measured benefit fits your images. Keep the fallback and verify the delivered result. That makes adoption an incremental change instead of a compatibility bet.