Convert JPG to JXL

JPEG XL has a capability nothing else in this family has: it can take an existing JPEG, repackage its coefficients without ever decoding them to pixels, and produce a file roughly twenty per cent smaller from which the original JPEG can be reconstructed byte for byte. Nothing is lost, nothing is added, and the operation is reversible. It is the strongest argument anyone has made for moving a photographic archive to the format.

This converter does not do it. Every image conversion on this site decodes its source to raw pixels and encodes the result afresh — that is the shape of the whole pipeline and there is no exception for this pair. What you get back is therefore a new lossy encode of your photograph: smaller, slightly different, and not convertible back into the file you started with. Saying so is the entire reason this page is written by hand rather than generated.

The JPEG is decoded by mozjpeg to an 8-bit RGB buffer, and libjxl encodes that buffer at the quality you choose, defaulting to 82. The result on this site’s own sample photograph is 8,924 bytes of JPG becoming 7,240 bytes of JXL — nineteen per cent smaller, which is close enough to the recompression figure to be confusing and is arrived at by a completely different route.

The difference matters more than the number. Nineteen per cent from re-encoding costs a generation of quality and cannot be undone; nineteen per cent from recompression costs nothing and can be undone at any time. If the saving is what you want and the exactness is not, this page is fine. If you were promised both, you were reading about cjxl.

libjxl ships two command-line programs, cjxl and djxl, and they are free, open-source and available for Windows, macOS and Linux. cjxl given a JPEG performs the lossless transcode by default, and djxl reverses it and hands you back the original JPEG. For a large library that is a script and an afternoon, and the result is genuinely reversible.

The reason it is not available here is architectural rather than ideological. This pipeline is built around decoding to pixels and encoding again, which is what makes a hundred format pairs work through one path, and a coefficient-level JPEG transcode is a special case that bypasses all of it. That is worth knowing rather than working around: a browser converter is the wrong shape for the job, and the right tool for it is a download away.

A JPEG has already thrown information away, and what remains includes its own artefacts: eight-by-eight block boundaries in flat areas, ringing along hard edges, and colour stored at half the resolution of brightness. Those are now simply the picture, and the JXL encoder spends bits reproducing them accurately while quantising afresh on top.

How much that hurts depends entirely on the original. A JPEG straight out of a camera at high quality survives a re-encode at 82 with very little visible change. A JPEG that has been through a messaging app, been screenshotted, or been saved at quality 60 has visible artefacts already, and the second pass makes them slightly worse rather than smoothing them. If the raw file or a lossless export still exists, encoding from that is strictly better — and if it does not, this is a fair trade only where the saving is worth a small step down.

The control runs from 1 to 100 and starts at 82. Because the source is already lossy there is an argument for setting it a little higher than you would from an original: the encoder is trying to reproduce a picture that contains structure it did not put there, and giving it more room means less of that structure is smeared further.

The top of the range behaves differently and is worth knowing. Measured through this site’s own encoder: at quality 100 a 256 by 256 gradient came back with 334 of 262,144 samples off by one level, and flat artwork came back bit-identical — near-lossless with respect to the decoded pixels, though not with respect to your JPEG file. The resulting JXL is much larger than the JPEG at that setting, so quality 100 makes sense only when the file is going into a workflow that will re-encode it again, not as a storage strategy.

A JPEG carries EXIF, XMP, IPTC, an ICC profile and often GPS coordinates, and for a photograph collection those are frequently as valuable as the pixels — the date, the camera, the lens, the location, the caption, the copyright line. None of it survives, because the conversion decodes to raw pixels and re-encodes, and that is unconditional rather than something the page lets you decide.

For a single photograph being sent somewhere that is often welcome, since it also removes the coordinates of the house it was taken in. For a library migration it is a serious problem and it is the second reason, after reversibility, that cjxl is the correct tool for that job: it preserves the whole metadata block along with the coefficients. Losing an ICC profile also flattens saturated colour slightly, because an untagged file is read as sRGB by whatever opens it next.

On this site’s own sample photograph at the default quality, the same picture is 8,924 bytes as JPG, 14,700 as WebP, 17,599 as AVIF and 7,240 as JXL. JPEG XL is the smallest of the four, which is the technical case for the format in one line — and mozjpeg’s JPEG is second, which is a reminder that a well-encoded JPEG is not the weakling it is often described as.

Support runs in exactly the opposite order. JPG opens everywhere, WebP opens in every current browser, AVIF in modern ones, and JXL in some. For a photograph that has to be sent, published or handed over, that ordering dominates and JPG or WebP is the right answer. JPEG XL wins only where the files stay inside a system you control.

The case for is genuine: about a fifth of the disk back, or more with the lossless transcode, on collections that are frequently hundreds of gigabytes. The case against is that JPEG is the most universally readable image format there has ever been, and a library that stops opening in the software you use is worth much more than the storage it costs.

The defensible middle is to keep the JPEGs and treat JXL as an experiment, or to use cjxl so the migration is reversible and nothing is actually at risk. What is not defensible is converting a twenty-year archive through a browser at quality 82 and deleting the originals, which is the reading of "JPEG XL saves twenty per cent losslessly" that this page exists to prevent.

mozjpeg decodes and libjxl encodes, both compiled to WebAssembly and both fetched only when they are needed, entirely inside your browser. Nothing about the photograph crosses the network, which matters for the material that ends up on this page — personal archives, client shoots, unpublished work.

The free limit is 100 MB per file, far beyond any JPEG. Batches work: drop a folder, each file converts with its own progress row, and the results come back as a ZIP. JPEG XL encoding is slower than WebP and faster than AVIF, so a few hundred photographs is a walk away. Convert a handful first, look at them at full size against the originals, and decide whether the nineteen per cent is worth the generation before committing anything larger.