thecompressjpeg

What is JPEG XL?

Technically the most interesting format of the modern crop — it can repack an existing JPEG 20% smaller and turn it back byte for byte. Its problem has never been the technology.

JPEG XL at a glance

Extension
.jxl
Standardised
ISO/IEC 18181, by the JPEG committee itself.
Signature feature
Lossless JPEG transcoding — repack a JPEG ~20% smaller, fully reversible.
Modes
Lossy and lossless, both strong. Alpha, animation, HDR, wide gamut.
Encode speed
Much faster than AVIF, comparable to or better than JPEG.
Progressive decoding
Yes, and better than JPEG's.
Browser support
Contested. Safari ships it; Chrome does not; Firefox keeps it behind a flag.
On this site
Not supported — browsers cannot decode or encode it without a WASM library.

Understanding JPEG XL

The feature nothing else has

JPEG XL can take an existing JPEG and repack it roughly 20% smaller, losslessly — and then reconstruct the original JPEG file byte for byte on demand.

That is a genuinely unusual property. Every other modern format requires decoding your JPEG and re-encoding it, which means a second lossy pass and irreversible change. JXL transcoding introduces no generation loss and is completely reversible.

For anyone holding a large archive of JPEGs, that is a compelling proposition: a fifth off the storage bill with no quality decision to make and no risk of regret. It is the single strongest argument for the format.

What else it does well

Speed. Encoding is dramatically faster than AVIF and competitive with JPEG. For anything encoding on demand rather than at build time, that difference decides the matter.

Quality at the top end. JXL holds up better than AVIF at high fidelity, which suits photography and archival work where you are not trying to squeeze the last byte.

Lossless. Its lossless mode beats PNG substantially, and unlike WebP it has no dimension limits to worry about.

Progressive decoding, better than JPEG's — a usable preview arrives very early, which matters on slow connections.

Range. Alpha, animation, HDR, wide gamut and very high bit depths, all in one format.

Why you probably still cannot use it

Browser support is the entire problem, and it has been unusually political.

Chrome implemented JPEG XL behind a flag and then removed it, citing insufficient ecosystem interest — a decision that drew considerable public objection from image and archival communities. Safari added support and ships it. Firefox has kept an implementation behind a flag rather than enabling it.

The position has shifted more than once and may shift again, so treat any snapshot of it as provisional and check current support before building on it. What is stable is the conclusion: as long as the largest browser does not ship it, JPEG XL is not a format you can serve on the open web without a fallback for the majority of visitors.

Where it is genuinely useful today

Outside the browser, the calculation changes completely.

  • Archival storage. Lossless JPEG transcoding is close to free storage savings for anyone holding millions of images.
  • Internal pipelines where you control every client.
  • Professional photography workflows, where high-fidelity lossy and true lossless in one format is convenient.
  • Apple-only contexts, since Safari and recent macOS handle it.

For a public website, AVIF or WebP remain the practical answers.

Why there is no JPEG XL tool here

Every tool on this site runs in your browser and uses the browser's own codecs. No mainstream browser exposes a JPEG XL encoder to a web page, and most cannot decode it either.

Supporting it would mean shipping a WebAssembly build of libjxl — a substantial download for a format most visitors cannot use anyway. Rather than offer a page that would fail for the majority, there is no JXL tool. If you need one, cjxl and djxl from the reference implementation are the tools to reach for.

Try it yourself

Everything below runs in your browser, so you can test any of this on your own files without uploading them.

  • JPG to WebP

    Typically 25–35% smaller at matched quality. The standard web win.

    Open the tool

  • Compress JPEG

    Shrink JPG and JPEG photographs with a quality slider or an exact target size.

    Open the tool

  • Compress WebP

    Re-encode existing WebP files, or convert JPEG and PNG into WebP.

    Open the tool

  • Lossless compressor

    Zero quality loss, every pixel preserved exactly. Honest about how modest the saving is.

    Open the tool

Questions

Frequently asked questions

Every answer below is present in the page source, expanded, so it can be read without opening anything.

Can browsers display JPEG XL?

Safari does. Chrome implemented it behind a flag and then removed it, and Firefox keeps its implementation disabled by default. The position has changed more than once, so check current support before relying on it — but as long as Chrome does not ship it, JXL is not usable on the open web without a fallback.

What makes JPEG XL different from AVIF?

Lossless JPEG transcoding, which nothing else offers: it repacks an existing JPEG about 20% smaller and can reconstruct the original byte for byte. It also encodes far faster and holds up better at high quality. AVIF compresses harder at low bitrates and has far broader browser support.

Is JPEG XL lossless?

It supports both. Its lossless mode beats PNG substantially, and its lossy mode is competitive with AVIF — particularly at higher qualities. The lossless JPEG transcoding is a third, separate capability.

Should I convert my photo library to JPEG XL?

For archival storage where you control the software, the lossless JPEG transcode is attractive — a fifth off your storage with no quality loss and full reversibility. For anything you need to open on arbitrary devices or serve on the web, not yet.

Why can't I convert to JPEG XL here?

Because browsers do not provide a JPEG XL encoder, and most cannot decode the format either. Adding it would mean shipping a large WebAssembly library for a format most visitors could not use. Use cjxl from the reference implementation instead.

Is JPEG XL dead?

No — it is standardised, actively maintained, shipped by Safari and used in professional and archival workflows. What it lacks is universal browser support, which is what would make it viable for the open web.

From the blog

Related reading

Longer, more practical guides from the blog.

  • Image Formats

    WebP vs JPEG: Which Should You Use, and When JPEG Still Wins

    WebP produced a 27.0 KB file against MozJPEG's 41.1 KB on the same photograph at slightly higher measured fidelity — 34% smaller. It also produced a larger file than JPEG on random noise. The advantage is real and content-dependent.

    9 min read

  • Image Compression

    JPEG Quality Settings Explained: What the Number Actually Means

    Quality 80 is not 80% of anything. It is an index into a quantisation table. Measured on one photograph: dropping from 100 to 90 removes 77% of the file and 4.2 dB of fidelity; dropping from 40 to 30 removes 17% and costs almost as much.

    8 min read

  • Practical Guides

    How to Compress Images for a Website Without Wrecking Them

    Resize before you compress. Measured on one photograph: half the width at quality 80 produced a 16.4 KB file, while full width at quality 40 produced 20.6 KB and looked far worse. The order of operations matters more than the settings.

    8 min read