What is a JXL file?

JXL is a binary format, meaningful only to a program that knows it. It stores a grid of pixels, so enlarging it past its own resolution softens it. It is used for archiving and photography.

The extension is .jxl, and the full name is JPEG XL. Both matter less than what the file can hold, which is what the rest of this page is about.

Joint Photographic Experts Group published it in 2021. The specification is ISO/IEC 18181.

Age is worth knowing here for one practical reason: the older a format is, the more programs have had time to learn it.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

It exists to do one job well for one group of people. Outside that job it is a poor default, and inside it there is usually nothing better.

JXL stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

JXL carries an alpha channel, so a logo keeps its soft edges over whatever sits behind it instead of arriving in a white box.

JXL can store an animation rather than a single still. That is worth knowing before converting one: a target that holds one frame keeps the first and drops the rest, usually without saying so.

Up to 32 bits per channel. It can work in RGB, greyscale and wide-gamut colour.

More than eight bits per channel is what stops a gradient from stepping when it is edited, which is why it matters in a working file and rarely in a finished one.

GIMP and ImageMagick read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

Only some browsers read it.

Where support is uneven, serving a second format alongside it is the usual answer — the browser takes the one it understands and nobody is left out.

JXL can hold EXIF, XMP and ICC profiles.

Whether any of it survives a conversion depends entirely on the target, and the honest answer is usually "some of it".

JXL is meant to be handed over rather than worked in. Editing one is possible and rarely pleasant; the sane approach is to change the source and export again.

The recurring complaints: support outside its home ground is uneven.

None of these is a reason to avoid the format. They are the things worth knowing before you are surprised by one, which is a different claim and a more useful one.

This is the capability nothing else has. JPEG XL can take an existing JPEG, re-encode it about 20 per cent smaller, and later reconstruct the original file byte for byte — not a visually identical image, the same file, with the same checksum.

That changes what is being asked. Converting a photo library to WebP or AVIF means committing: the JPEGs are re-encoded through a second lossy pass, and the originals are either kept alongside or gone. Recompressing to JXL is reversible, so a twenty-year archive can be made a fifth smaller with nothing at stake. No other format offers this, and it is the strongest argument the format has.

JPEG XL has a lossy mode competing with AVIF and a lossless mode competing with PNG, and unlike WebP’s two modes these share a design rather than being two compressors under one extension. Lossless JXL is typically 30 to 40 per cent smaller than PNG.

It also supports progressive decoding — a partially downloaded file renders as a lower-resolution version of the whole image rather than the top few rows. AVIF reaches something similar only through a layered encode that almost no encoder produces, and on a slow connection it is the difference between seeing something immediately and seeing nothing.

Chrome implemented JPEG XL behind a flag and then removed it in 2023, saying the ecosystem interest was insufficient to justify maintaining it. The decision was contested at length by photographers, browser engineers and the image-compression community, and it effectively stalled the format on the web.

Apple then added support in Safari 17 in 2023, and it works across macOS and iOS. So the position today is genuinely split: Safari yes, Firefox behind a flag, Chrome no. A format with an unusually strong technical case and unusually poor luck, and the reason a JXL file may simply not display for the person you send it to.

Safari on macOS and iOS, which is a substantial share of image traffic. Adobe’s applications, which added support. A growing set of image tools and libraries. Some camera manufacturers have shipped it as a capture option.

The practical consequence is that JXL currently makes sense as a storage and archival format rather than a delivery one. Compressing a library on your own disk is a decision you control; putting JXL on a public web page means a large share of visitors see nothing.

JPEG XL was standardised in 2022 out of two submissions: Google’s PIK and Cloudinary’s FUIF, itself descended from FLIF. The result carries ideas from both, which is why it handles photographic and synthetic images well rather than being tuned for one.

The lineage matters for one practical reason: the JPEG recompression feature came from deliberate design rather than a happy accident. The committee set out to make the existing JPEG corpus migratable, and that goal shaped the format.

Up to 32 bits per channel, wide colour gamuts and HDR. A proper alpha channel in both lossy and lossless modes. Animation. Images far larger than other formats permit — the dimension limits are effectively theoretical rather than practical.

It also encodes considerably faster than AVIF, which is AVIF’s main weakness. On that axis JXL is the more practical of the two modern formats, which makes its position on the web more frustrating rather than less.

If you are recompressing an existing JPEG, use the lossless JPEG recompression mode, which is reversible and costs nothing. If instead you encode that JPEG through JXL’s ordinary lossy mode, you are putting an already-compressed image through a second lossy pass and the damage compounds.

The two operations look similar in a tool’s interface and are completely different in what they cost. It is the single most useful thing to get right when working with the format, and it is easy to get wrong because the distinction is rarely made prominent.

JPG when the file has to reach someone whose browser or software will not display JXL, which today means most people. Expect a larger file at the same visible quality. PNG when the image has transparency or is a screenshot or diagram.

Bit depth is the loss to watch. A JXL carrying more than eight bits per channel converted to JPG or PNG has fewer levels available in gradients, which can band a sky. Keep the JXL — given its position, it is very likely the archival copy and the converted file is the one you send.

For a personal archive on your own storage, the JPEG recompression alone is a strong case: a fifth smaller, fully reversible, nothing risked. That is a rare offer and it does not depend on browsers agreeing about anything.

For anything published, not yet. Without Chrome the format cannot be served as a primary image, and maintaining a fallback for the majority removes most of the benefit. That may change — Safari’s support was itself a reversal of the trend — but a decision made today should rest on where it works now rather than on where it deserves to be.