Convert JXL to WebP

JPEG XL lost the browser argument. Chrome carried it behind a flag, removed the decoder in 2023 and has not restored it; Safari shipped it and kept it. That split is the reason this page has visitors: a photograph that renders perfectly on a Mac is a broken image icon for the majority of an audience, and nothing about the file is wrong.

WebP is the other side of that history. Google published it in 2010, it is specified in RFC 9649, and every current browser reads it — as do the upload forms, the content management systems and the chat clients that sit between you and the person who has to see the picture. The conversion is not an upgrade in any technical sense. It is an exchange of fidelity for reach, made deliberately.

Browser support is the headline, but it is not the part that costs most people an afternoon. The failures cluster around the software nobody thinks about: a WordPress media library that rejects the extension, a Slack preview that stays blank, a Windows colleague whose Photos app shows nothing, a product feed validator that refuses the file outright. None of those will show you a useful error; most simply behave as though you attached nothing.

JPEG XL has GIMP and ImageMagick on its side and comparatively little else in the consumer tier. WebP arrives with Photoshop, GIMP and Squoosh reading it directly and near-universal handling everywhere a file gets uploaded rather than opened. If the destination is a form, a feed or somebody else's inbox, that difference decides the conversion on its own.

JPEG XL allows up to 32 bits per channel and describes wide-gamut colour natively, which is a large part of why it was proposed as an archival format. WebP stores 8 bits per channel and nothing more. Any headroom the original carried for exposure correction or gamut mapping stops at this conversion.

The pipeline makes that concrete before the encoder ever runs. The JPEG XL decoder returns 8-bit RGBA pixels, and everything downstream works on that buffer, so the reduction happens on the way in rather than as a compromise inside the WebP encoder. Keep the JPEG XL. It is the master copy, and once these pixels are 8-bit there is no route back to the depth that was in the original.

This one surprises people converting scans and panoramas. The WebP container encodes image dimensions in 14 bits, so 16,383 pixels is the hard maximum on each axis — not a setting, not a tier, a limit written into the format. JPEG XL has no comparable ceiling in ordinary use, which is one of the reasons it was proposed for scanning and archival work in the first place.

The maximum-width control on this page is the answer when a file runs past it. Set a width the destination actually needs — 2,000 pixels is generous for a full-bleed web image — and the conversion resizes before encoding. If the whole point of the file is that it is 20,000 pixels wide, WebP is the wrong target and TIFF or PNG is the honest recommendation instead.

Both formats carry a full alpha channel, so this is one of the few conversions on the site where transparency is a non-event. A cut-out product shot or a logo with soft edges converts with no background colour to pick, no fringe, and no decision to get wrong afterwards.

That is worth contrasting with the alternatives people consider from the same starting point. Going to JPG or BMP means flattening the alpha onto a chosen colour, and if the image will sit on more than one background that choice is a permanent mistake. Where transparency exists in the source, WebP and AVIF are the only two mainstream delivery targets that keep it.

JPEG XL can hold animation and so can WebP, which makes this the disappointing case: the decoder used here returns a single image, so an animated source comes out as a still. The first frame is what you get, and the rest of the file is discarded silently by the codec rather than by any choice made on this page.

If the motion matters, the picture format is the wrong destination entirely. A short clip as MP4 or WebM is typically a fraction of the size of the equivalent animation and plays with hardware decoding on every phone. Treat this conversion as a way to get a poster frame out of an animated file, not as a way to move the animation.

The default is 82, which is the point where the re-encode is invisible at normal viewing size on most photographs. Because the source is already a compressed image in most cases, this is a second generation of lossy compression, and the artefacts that stack are the ones around hard edges and text rather than in open sky. The one case where the default is clearly wrong is an image that was already compressed hard once, where a second pass at 82 will visibly sharpen what the first pass smeared.

Raise it towards the mid-nineties for screenshots, diagrams and anything with one-pixel lines or small type — that is where a second pass shows first. Lower it below 70 only for decorative backgrounds nobody inspects. And convert from the JPEG XL every time you need a new size rather than re-encoding the WebP, because each pass through a lossy codec starts from the previous one's mistakes.

JPEG XL can hold EXIF, XMP and an ICC profile. None of it reaches the output here. The conversion decodes to raw pixels and encodes again, which is a round trip no metadata block survives. There is no switch for it on this page, because there is nothing for a switch to decide: the pixels are all that crosses.

That is usually the outcome people want on a web image — the GPS coordinates of the house a photograph was taken in have no business in a page asset — but it is a loss where the file is also the record. If the capture date, the camera model or the colour profile matter to you, keep the JPEG XL alongside the WebP rather than replacing it. And note the profile in particular: an untagged WebP is interpreted as sRGB by every viewer, so a wide-gamut original can shift visibly.

WebP has two modes. The lossless one stores exact pixels and is the right choice for flat graphics; the lossy one is a still frame of the VP8 video codec and is what almost every WebP on the web actually is. This conversion writes the lossy mode, at the quality you set, with no switch to change it.

One detail of that encoder is worth knowing because it works in your favour: the alpha channel is compressed separately from the colour and at full quality by default, so the transparency stays crisp even when the picture itself is being compressed hard. If you need genuine lossless output from a JPEG XL, PNG is the target on this site that provides it, at a considerably larger file.

Drop the whole directory. Each JPEG XL is decoded and re-encoded in turn on your own processor, keeps its filename with the extension swapped, and the set comes back as a single ZIP. There is no queue, no per-file wait and no daily allowance, because there is no server doing the work. The engine itself is fetched once, on demand, the first time a conversion runs on the page — a visitor who only reads the text downloads none of it.

The privacy argument is stronger here than the general one, because of who ends up with JPEG XL files. They come from photographers testing an archival codec, from Apple devices, and from people who chose the format on purpose — which is to say from libraries of personal photographs rather than from stock imagery. Files up to 100 MB convert on the free tier, and none of them leaves the machine you are sitting at.