Convert WebP to JXL

This site keeps three sample scenes and encodes them through the same pipeline this page uses, so the numbers are what this converter produces. At 480 by 320 and the default quality: the photograph is 14,700 bytes as WebP and 7,240 as JXL — the smallest figure in the entire sample set, below AVIF’s 17,599 as well. The flat graphic is 4,428 as WebP against 5,016 as JXL. The screenshot-like scene is 10,830 as WebP against 13,252 as JXL.

So the reputation is earned on continuous tone and not across the board. JPEG XL’s modular and VarDCT modes were built with photographic material squarely in mind, and on a photograph at a moderate quality it is the strongest of the four codecs this site can write. On flat, hard-edged, text-bearing content it is not, and AVIF is the better answer there — 5,081 bytes for the same screenshot. A library of photographs is a good candidate for this conversion; a folder of interface assets is not.

This is the most common misunderstanding about JPEG XL and it is worth settling before anything else. JXL can take an existing JPEG file and repackage it losslessly, saving roughly twenty per cent while allowing the original JPEG to be reconstructed byte for byte later. It is a genuinely clever feature and it is specific to JPEG’s coefficients.

It has no equivalent for WebP, whose coding is unrelated. And it is not what happens on this site in any case: every image conversion here decodes to pixels and re-encodes, on every pair including JPG to JXL. So the file you get back is a fresh encode rather than a repackaging, it cannot be turned back into the WebP you started with, and the twenty-per-cent figure quoted in articles about JPEG XL is not the number to expect from this page.

The quality control runs to 100 and the encoder behaves differently at the top of the range, so the number is worth pinning down. Measured through this site’s own encoder on a 256 by 256 test image: at the default 82 a gradient came back with 73,647 of its 262,144 samples changed, the worst by 21 levels. At 100, 334 samples differed and none by more than one level, and flat artwork at 100 came back bit-identical.

That is near-lossless rather than lossless. The encoder’s dedicated lossless mode exists in the library and is not exposed here, so a claim that the JXL is a lossless copy would be wrong. Practically: 82 for anything that will only ever be looked at, 100 if the file is going into a workflow that will re-encode it again, and neither if what you actually needed was a bit-exact archive copy — WebP to PNG is that.

WebP is read by every current browser without a fallback, and that is why it exists and why most of these files are WebP in the first place. JPEG XL is read by some, which is a materially different situation: an image that cannot be decoded is not a degraded image, it is nothing at all.

That makes this a storage conversion rather than a delivery one, and the distinction is worth holding on to. Keeping a photograph library as JXL and generating WebP or AVIF for the pages that serve it is a coherent plan. Replacing the WebP files a site is serving with JXL files is not, and no picture-element fallback saves you if the fallback is the file you just deleted. Keep the WebP if the WebP is what the site serves.

Most WebP files that arrive here were produced in lossy mode — that is the default for anything a CMS, a CDN or a build pipeline generates for delivery. The encoder has already smoothed flat regions and left ringing along hard edges, and those artefacts are simply the picture now.

The JXL encoder reproduces them faithfully and adds a layer of its own. At quality 82 the result is modest and at quality 60 it is not. The way to avoid it entirely is to go back a step: if the original PNG or JPG still exists in a repository, an asset system or a design tool, encoding JXL from that produces a cleaner and usually smaller file than encoding it from the WebP. This page is for the case where the WebP is what survives, and in that case a second generation is simply the price.

Both formats carry a full 8-bit alpha channel, so a cut-out image comes through with its transparency intact and its soft edges still soft. Nothing needs to be flattened and no background colour is involved, which is one of the reasons this pairing is cleaner than converting a WebP to JPG or BMP.

Metadata does not travel. EXIF, XMP and any ICC profile are dropped, because the conversion decodes to raw pixels and re-encodes, and that is simply what happens rather than a choice the page offers you. JPEG XL itself can carry all three, so this is a limitation of the pipeline rather than of the format — worth knowing if the plan was to build a catalogued library, where the metadata usually matters as much as the pixels.

WebP holds either a still image or an animation, and the decoder used here reads only the first kind. An animated file produces a readable error instead of a first frame — the better of the two failures, and the same behaviour across every WebP pair on this site.

JPEG XL can hold animation, so in principle the frames would have had somewhere to go; nothing in this pipeline extracts them, so the case does not arise. For a folder that mixes stills and animations, the batch converts the stills and reports the rest as errors, which is the outcome to want: a set of silent one-frame JXL files that used to be animations would be much harder to notice and much harder to undo.

GIMP and ImageMagick read and write JPEG XL directly, which covers scripted workflows, batch processing and most technical use. Photoshop needs a plug-in. Windows and macOS previews are inconsistent, and a large amount of ordinary software — office suites, upload forms, older photo managers — shows an unknown-file icon and nothing else.

That narrowness is the whole practical argument, and it is why the format is marked niche rather than current despite being technically the strongest thing here. The two honest uses are a closed workflow you control, and deliberate experimentation with the originals kept safely elsewhere. Anything that has to be opened by a person you have not spoken to should stay WebP, or become PNG or JPG.

libwebp decodes and libjxl encodes, both compiled to WebAssembly and both fetched only when a file of that type is dropped, so a batch downloads each codec once. Nothing about any file crosses the network, and there is no account or daily allowance in the way.

The free limit is 100 MB per file, far beyond any web asset. Drop a folder and each file converts with its own progress row, with a ZIP at the end. JPEG XL encoding is slower than WebP and faster than AVIF, so a few hundred files is a walk away rather than an afternoon. Convert a handful first and compare the byte counts against the originals — on the wrong content this conversion makes files larger, and finding that out on five images is cheaper than finding it out on five thousand.