Convert JXL to JPG

This is the one conversion on the site driven almost entirely by politics rather than by pixels. JPEG XL is technically the stronger format: same committee as JPEG, standardised as ISO/IEC 18181, lossless and lossy in one codec, up to 32 bits per channel, alpha, animation and wide colour. On the merits it should have replaced JPEG outright.

It did not. Chrome carried a JPEG XL decoder behind a flag and removed it in 2023; Safari shipped it in version 17 and still has it; Firefox has never enabled it by default. The registry files it under partial browser support and patchy support as a known problem, and that is the whole reason this page exists. Nobody converts away from JPEG XL because the picture is wrong. They convert because something refused to display it.

JPEG XL has a feature no other format has: it can take an existing JPEG and repack it losslessly, storing the same picture around twenty per cent smaller with the original coefficients intact. Nothing is re-compressed, and libjxl’s own decoder can rebuild the original JPEG byte for byte from that repacked file. A great deal of the JPEG XL in the wild was made this way.

This converter cannot do that, and saying so is more useful than pretending. The browser-side decoder here hands back a grid of pixels, not the JPEG reconstruction data, so the JPG you download is encoded fresh from those pixels — a second generation, with a second round of JPEG loss on top of the first. If the JXL was made from a JPEG you still have, that original is strictly better than anything this page can produce. If you do not have it, this is the right tool and the loss at quality 82 is small.

Quality defaults to 82 on a 1 to 100 scale. That is a delivery setting: on a photograph at normal viewing size it is difficult to fault by eye, and it produces a file most people would call small. For a picture that is going into an email, a listing or a form, leave it alone.

Raise it when the JPG is not the last step. Every JPEG save quantises the image again, and because this conversion is already a second generation, an edit-and-resave makes it a third. Ninety and above keeps enough headroom for that. There is no value that makes JPG lossless — the format has no lossless mode at all — so if the picture will be edited repeatedly, PNG is the better target and the JPEG XL is the better thing to keep.

JPEG XL stores an alpha channel and JPG has never had one. Where the source is see-through, the converter fills those pixels with a background colour before encoding, and the colour picker for it appears on this pair specifically because there is a real decision to make. White is the default because white is what most pages, documents and forms sit on.

The fill is skipped entirely when the picture is already opaque, which is nearly every photograph, so the option costs you nothing when it is irrelevant. It matters for logos, icons, product cut-outs and anything exported with a cleared background — and there the right question is whether JPG is the target at all. A cut-out flattened onto white is only correct until somebody puts it on a coloured slide, and the fringe of half-transparent pixels around an anti-aliased edge gets blended into the fill colour too, which is what produces the pale halo people notice on a dark background afterwards. If the picture will be composited, set the background to whatever it is landing on, or use a format with an alpha channel and avoid the question.

JPEG XL can hold up to 32 bits per channel and a wide colour gamut. JPG is an eight-bit format and always has been. The pipeline here decodes to eight-bit RGBA before it encodes anything, so a high-bit-depth or HDR JPEG XL is reduced to ordinary eight-bit sRGB whichever target you pick.

For a normal photograph this is invisible, because the source was eight bits to begin with. It shows on gradients in a wide-gamut file — a sky, a studio backdrop, a flat brand colour — where the extra precision was doing the work of hiding banding. If the file came out of a camera or an editor in HDR and the banding matters, the JXL is the master and the JPG is a copy for other people.

The registry lists EXIF, XMP and ICC as the metadata a JPEG XL can carry, and JPG can carry all three plus IPTC. None of it survives this conversion. Every browser-side image path here decodes to raw pixels and encodes again, and a pixel grid has no room for a camera model, a capture date, a GPS coordinate or a colour profile.

The “remove metadata” switch is on by default and is honest rather than decorative: it describes what happens either way. Treat that as a feature when you are sending a picture out — the coordinates of the place it was taken do not travel with it — and as a warning when you are not. If the EXIF matters, keep the JPEG XL alongside the JPG rather than replacing it.

JPEG XL supports animation. JPG holds exactly one still image and has no mechanism for a second frame, no matter what the source contained. There is no option that changes this, because there is nothing in the JPG specification for the option to set.

That makes JPG the wrong target for anything that moves. If the JPEG XL is animated and the animation is the point, the honest answers are formats that can hold frames rather than a still that discards them. If you only need one frame — a thumbnail, a preview, a still for a document — then a single image is what you wanted anyway and the conversion does exactly the right thing.

This is the uncomfortable half of the trade and it should be said before you download. JPEG XL is a 2022 codec and JPEG is a 1992 one, standardised as ITU-T T.81. The newer encoder reaches the same visible quality with fewer bytes, so going backwards costs bytes almost every time.

How many depends entirely on the picture and on the quality you choose, and any single percentage quoted here would be a guess dressed up as a fact. There is one case where it goes the other way: a JXL that is a losslessly repacked JPEG is about a fifth smaller than the JPEG it came from, so a fresh lossy encode at quality 82 can undercut it. The comparison worth making is the one on your own file: convert it, look at the two sizes, and decide whether the increase matters. For an email attachment or a form upload it almost never does. For a library of ten thousand images it is the whole argument for keeping the JPEG XL.

Both halves of this conversion are WebAssembly running in the tab: libjxl decodes the source, the JPEG encoder writes the result, and neither one makes a network request carrying your picture. There is no queue, no account and no server-side copy waiting to be deleted, because nothing was ever sent.

The practical consequences are worth more than the principle. A folder converts as fast as your processor manages rather than as fast as your upload allows, the free ceiling is 100 MB per file rather than a plan tier, and a photograph of something private stays private without anyone having to take a promise on trust. The network tab is the proof, and it is a better proof than a policy page.

If the file is an archive master, the conversion is the wrong move. JPEG XL is listed for archival and photography use precisely because it holds more and loses less, and a JPG made from it is strictly smaller in information than the file you already have. Convert a copy for the person who needs it and leave the original where it is.

The case for converting is delivery, and it is a strong one: somebody has to open this, and JPG opens on every device made in the last thirty years with no codec, no flag and no browser version to check. The rule of thumb is that the JXL is what you store and the JPG is what you send. Deleting the JXL afterwards is the only genuinely irreversible mistake available on this page.