The JPEG XL format

Where it came from

JPEG XL is the JPEG committee’s own successor to JPEG, standardised as ISO/IEC 18181 in 2021. It was assembled from two existing projects that were merged rather than designed from nothing: Google’s PIK and Cloudinary’s FUIF. The result carries two compression modes in one container — a DCT-based mode tuned for photographs, and a modular mode for lossless and non-photographic images — which is why it is competitive at both ends rather than only at low bitrates.

Everything else follows from being designed thirty years after JPEG: up to 16 bits per channel, HDR, wide gamut, an alpha channel, animation, progressive decoding that genuinely renders a usable image from the first fraction of the bytes, and encoding fast enough to use in a build step rather than overnight.

The trick nothing else has

JPEG XL can take an existing JPEG and repack it, losslessly, at roughly 20% smaller — and reconstruct the original file byte for byte on the way back out. Not visually identical: the same bytes, the same checksum.

For anyone holding a large archive of JPEGs that is a genuinely unusual offer, because it is a storage saving with no decision attached to it. Every other route to a smaller file asks you to accept a re-encode you cannot undo.

Worth being precise about what happens here, though: this tool decodes a JPEG XL to pixels like any other input. It does not unpack a repacked JXL back into its source JPEG. If your .jxl was made from a JPEG and you want that JPEG, you want a JPEG XL utility that performs the reconstruction — converting it here produces a new, different file that merely looks the same.

Why almost nothing opens one

Chrome shipped JPEG XL behind a flag in 2021, then removed the code in 2023 on the grounds that the ecosystem had not shown enough interest to justify maintaining it alongside AVIF. That decision was argued over loudly and did not change. Safari 17 shipped support in 2023, so Apple’s platforms display JPEG XL natively; Firefox has kept it behind a preference.

So the format sits in an unusual place: technically ahead of everything else on this site, and unusable for anything published to a general audience. Put one on a web page and a large share of visitors see a broken image.

Why we read it but do not write it

An encoder would be straightforward to add — libjxl compiles to WebAssembly and there are published builds. It is left out on purpose.

The reason is what the file would be for. Someone converting to a format wants something they can then use, and a JPEG XL is refused today by Chrome, by Windows’ own image viewer, by most content management systems and by most chat applications. Shipping the encoder would mean producing files that mostly cannot be opened, which is a worse outcome than declining. Decoding is the half of the problem that people actually have, so that is the half that exists, and the decoder is downloaded only when a .jxl is opened.

If browser support changes, so does that decision. It is scope, not principle.

What to convert it to

JPG when the file needs to open anywhere without a conversation. If the JXL was a repacked JPEG in the first place, this is the same photograph coming home, though not the identical file.

AVIF when you want to keep a modern format’s file sizes and still have it display. It comes from the same generation of compression research, reaches similar sizes on photographs, and unlike JPEG XL it opens in every current browser.

PNG when you need exact pixels for editing. Note that this pipeline works in 8 bits per channel, so a 16-bit JPEG XL is reduced on the way in whatever you convert it to.