JPG to JXL: Worth It for Archives, Not for the Web

You've got a drive holding 40,000 family photos and every one of them is a JPEG. JPEG XL is the only modern format that can meaningfully shrink that pile without degrading a single image. That's a real reason to care.

It's also close to the only one, because in 2026 you still can't put a JXL on a website and expect people to see it.

Where JXL actually displays right now

Safari 17 and up decodes JPEG XL natively, so it works on recent Macs and iPhones. macOS Preview and Finder handle it. Chrome and Edge do not display it by default. Firefox has an implementation behind a configuration flag, off for everyone who hasn't gone looking for it.

So: archiving, print workflows, and applications that specifically read JXL. Not web images, not email, not anything you're sending to a person whose setup you don't control. If you want the argument for why that will probably change, our piece on why JPEG XL will kill JPEG makes the case at length.

The trick that makes JPEG XL different

Every other modern format handles an existing JPEG the same way. It decodes the file to raw pixels and compresses those pixels again with a different method. That works, but you're re-compressing something already compressed, and a little more detail goes each time.

JPEG XL has a mode nothing else has. Rather than decoding and re-compressing, it repacks the JPEG's existing compressed data using a smarter arrangement of the same information. The result is around 22 percent smaller, contains everything the JPEG did, and can be turned back into the exact original JPEG bytes whenever you want. The migration is reversible. For anyone sitting on a large archive, that's the headline.

What you get in a browser, precisely

Worth being straight about this, since plenty of pages blur the two.

The converter here decodes your JPEG and re-encodes it with libjxl. With Lossless switched on, the JXL is pixel for pixel identical to the JPEG you fed in, so no new quality is lost. What it doesn't do is the bit exact repacking described above, which needs libjxl's command line encoder working on the original JPEG bytes directly.

There's a consequence you should expect. A pixel-lossless JXL made from a decoded JPEG is frequently larger than the JPEG was, because you're now storing every pixel exactly while the JPEG was allowed to approximate. If your goal is a smaller file, leave Lossless off and use the quality slider.

How to convert JPG to JXL

1. Open the JPEG XL Converter.
2. Drop your JPGs in, up to 30 MB each.
3. For smaller files, leave Lossless off and set quality around 75, which is the default and holds up well on photographs.
4. For an exact pixel copy, switch Lossless on and accept the larger file.
5. Convert, then download individually or as a ZIP.

This runs libjxl compiled to WebAssembly rather than relying on any browser feature, so encoding behaves identically in Chrome, Firefox, Safari, and Edge. Producing the file works everywhere. Viewing it back is the part that still depends on what you're running.

When not to convert

Don't convert website images. Chrome users are most of your traffic and they'll get a broken image. Don't convert anything you're about to send someone. Don't convert your only copy of anything, because whatever opens JXL on your machine today may not be installed on the machine you're using in five years.

Convert when you control both ends: your own archive, your own backup, a workflow where you know the software reads JXL. Keep the JPEGs. The whole appeal of JPEG XL is that it doesn't force you to burn bridges, so don't burn them voluntarily.

If you want smaller files that people can actually see today, AVIF is the better answer, with display support around 92 percent of browsers in use.