JPEG XL: The Best Image Format You Still Cannot Ship
JPEG XL: The Best Format You Still Cannot Ship
There is an uncomfortable gap between JPEG XL's technical merits and its practical usability. On compression efficiency, encode speed, decode speed, lossless performance, progressive rendering and feature breadth, JXL is the strongest of the modern image formats. It is also the one you most likely cannot deploy on a public website.
Both statements are true simultaneously, and most coverage of JPEG XL picks one and ignores the other. This guide covers what the format actually does, where it genuinely wins, and how to decide whether it belongs in your workflow in 2026.
What JPEG XL Is
JPEG XL is a royalty-free image format standardized as ISO/IEC 18181, finalized in 2022 by the JPEG committee — the same body behind the original JPEG standard. Files use the .jxl extension.
Its origin distinguishes it from its rivals. WebP is built on the VP8 video codec. AVIF is built on AV1. Both are video codecs taught to encode a single frame, and both inherit design decisions optimized for motion rather than stills.
JPEG XL was designed as an image codec from the start, merging two research projects: Google's PIK and Cloudinary's FUIF. Its ambition was explicit — replace JPEG, PNG, and GIF with one format rather than adding a fourth to the pile.
Two modes in one format
JXL contains two distinct compression engines:
- VarDCT — a variable-size DCT for lossy photographic compression, conceptually descended from JPEG but with far more adaptive block sizing.
- Modular — a predictive, entropy-coded mode for lossless compression and non-photographic content, conceptually closer to PNG or FLIF.
An encoder picks the appropriate mode, and a single decoder handles both. This is why JXL is credible as a PNG replacement and a JPEG replacement, where AVIF and WebP are noticeably stronger at one than the other.
It also works in the XYB colour space, a perceptually-derived space modelled on human cone response, which lets the encoder allocate bits according to what the eye actually notices.
The Feature That Should Have Won It
Lossless JPEG recompression is JPEG XL's most distinctive capability, and it is the one most likely to matter to you directly.
JXL can take an existing JPEG and re-encode it into a .jxl file roughly 20% smaller — then reconstruct the original JPEG byte-for-byte on demand.
Read that carefully, because it is unusual. This is not "visually lossless". It is not "re-encoded at high quality". The original file is recoverable exactly, bit for bit, including its metadata and its particular encoder's quirks.
The implications are significant for anyone holding a large JPEG archive:
- A 20% storage reduction with no quality decision to make
- No one-way conversion risk — you can always get the original back
- Fully reversible, so it is safe to apply to originals you cannot afford to degrade
Photo libraries, media archives, and CDN origin storage are all natural fits. It is one of the few compression wins available that carries genuinely no tradeoff, which is rare enough to be worth noting. Every other format in this space asks you to choose between size and fidelity; this one does not.
JPEG XL vs WebP vs AVIF
| JPEG XL | AVIF | WebP | |
|---|---|---|---|
| Standard | ISO/IEC 18181 (2022) | AOMedia (2019) | Google (2010) |
| Derived from | Purpose-built (PIK + FUIF) | AV1 video | VP8 video |
| Lossy quality | Excellent, best at high quality | Best at low bitrates | Good |
| Lossless | Excellent | Weak — barely beats PNG | Good |
| Encode speed | Fast | Slow | Moderate |
| Decode speed | Fast | Moderate | Fast |
| Progressive decoding | Yes, native | No | No |
| JPEG recompression | Yes, lossless | No | No |
| Max bit depth | 32-bit float | 12-bit | 8-bit |
| Animation | Yes | Yes | Yes |
| Browser support | ~15% | ~93% | ~97% |
Where each one genuinely wins
AVIF wins low-bitrate lossy photography. If you are compressing photographs aggressively for a bandwidth-constrained context, AVIF holds detail better than JXL at the very bottom of the quality range. This is a real advantage and it is AV1's heritage showing.
JPEG XL wins nearly everything else. High-quality lossy, all lossless, flat-graphic and text-heavy images, encode speed, decode speed, and progressive rendering. The encode speed gap is not marginal — AVIF encoding is slow enough that it materially affects build times and CDN transformation costs at scale.
WebP wins on ubiquity and simplicity. It is not the best at anything technically, but 97% support and a decade of tooling maturity is a real argument. Our AVIF vs WebP comparison covers that pairing in depth.
Progressive decoding deserves a mention
JXL supports true progressive decoding: a low-resolution preview renders from the first fraction of the bytes and refines as more arrive. Neither AVIF nor WebP can do this.
On slow connections and large hero images this changes perceived performance meaningfully — something appears immediately instead of after the full download. It is the sort of feature that does not show up in a file-size benchmark but is very visible to an actual user.
The Browser Support Problem
Here is where the story turns.
- Safari — supported natively since Safari 17 (iOS 17 / macOS Sonoma). Apple has integrated it broadly across the OS, not just the browser.
- Chrome — shipped behind a flag from Chrome 91, then removed in Chrome 110 in early 2023, with Google citing insufficient ecosystem interest. In January 2026 the Chromium team merged a new Rust-based JXL decoder; as of Chrome 145 it is present but disabled by default, behind
chrome://flags/#enable-jxl-image-format. - Firefox — available in Nightly builds only, never enabled by default for release users.
Effective public-web support is Safari-only, roughly 15% of global traffic.
The Chrome removal in 2023 was the decisive event. Without Chrome, JXL could not become a default web format, and the absence of a web market discouraged the tooling investment that might have changed Chrome's calculation. The Rust decoder landing in 2026 is a genuinely encouraging signal — a memory-safe decoder addresses the security objections that dogged the C++ implementation — but "present behind a flag" is not "shipped", and the gap between those states has historically been measured in years.
What To Actually Do in 2026
For public websites: do not ship JXL as primary
Serving JPEG XL to the open web today means encoding a format most visitors cannot decode, while maintaining full fallbacks for everyone else. You take on the complexity of an extra format and the benefit reaches a minority.
Ship AVIF or WebP with a JPEG fallback. That is the boring, correct answer:
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="…">
</picture>
Our guide to choosing an image format for websites covers the decision in more detail, and optimizing images for the web covers the surrounding workflow.
You can add a <source type="image/jxl"> at the top of that block — the <picture> element degrades cleanly. Whether the extra encode and storage is worth reaching Safari users slightly more efficiently is a judgment call, and for most sites the answer is no.
For archival storage: use it now
This is where JPEG XL is straightforwardly worth adopting. Lossless JPEG recompression gives you ~20% off a photo archive with zero risk and full reversibility. You are not depending on anyone's browser — you control the decoder, and you can reconstruct the original JPEGs at any point.
For Apple-platform work: use it now
If you are building for macOS or iOS, JXL is natively supported across the system. Full 32-bit float, HDR, and wide-gamut support make it a strong fit for photography applications specifically.
For photography workflows: worth evaluating
Between raw formats and delivery JPEGs sits a large intermediate archive that most photographers never compress because the available options all cost quality. JXL's lossless mode is a real answer to that, and it handles high bit depths that WebP simply cannot represent.
An Honest Summary
JPEG XL is a better image format than the two that beat it to market. That is not really in dispute among people who work on image codecs.
Formats do not win on merit alone, though — they win on decoder availability, and decoder availability is decided by a small number of browser vendors. AVIF won the web because Chrome shipped it. JXL did not because Chrome did not.
So use JXL where you control the decoder, which is a larger space than it first appears: archives, internal pipelines, Apple platforms, photography workflows. Ship AVIF or WebP to the public web. Revisit when Chrome flips the flag to on by default — and it is worth revisiting, because the format deserves it.
Meanwhile, Compress What You Have
Format debates are worth following, but most real storage and bandwidth savings come from doing the ordinary thing well: right format for the content type, sensible quality settings, and images sized to their actual display dimensions.
Compresto handles that on macOS — JPEG, PNG, WebP, HEIC, TIFF and SVG, with batch processing, hardware acceleration, and no uploads. It runs locally, so your originals never leave your machine.