Convert a WebP to JPG, choosing what happens to transparency

The one thing JPEG cannot do

JPEG has no alpha channel. It was finished in 1992 for photographs, and a photograph has no transparent parts, so the format has no way to record one. That is not a limitation anyone is going to fix: the bitstream has no place to put it.

So every transparent pixel in the source has to become an opaque one, and the only question is which colour. White is the usual answer because most documents and most web pages are white. It is the wrong answer on a dark page, where a logo converted onto white arrives inside a white rectangle — the single most common complaint about this conversion, and it is not a bug in the converter.

The choice is permanent. Once the file is a JPEG the alpha information is gone and no later step recovers it, which is why this tool detects transparency in the source and raises the point rather than deciding quietly. If the destination really needs transparency, converting to PNG keeps it, and lossy WebP kept it in the first place.

Two lossy passes, and how to make the second one cheap

A lossy WebP has already discarded detail. Decoding it and encoding a JPEG discards more, and the two codecs do not discard the same things — WebP works in a different transform and with different quantisation, so its artefacts are not what a JPEG encoder expects to see. The result is that the second pass spends bits preserving the first pass's mistakes.

The practical remedy is to set the quality higher than you otherwise would. At 92 the second pass is effectively transparent: the file is larger than the WebP was, and nothing visible has been lost beyond what the WebP already lost. At 70 the compounding shows, particularly along edges and in flat gradients like a sky.

If the source WebP was lossless — an exported graphic, a screenshot — none of this applies, because there is only one lossy pass. It is still worth keeping the quality high for anything with text in it, where JPEG's ringing is at its most visible and where PNG would be the better destination anyway.

When this conversion is the right move

It is not for the web. Every browser in current use displays WebP, and converting a web image to JPEG makes it bigger for no benefit. The reasons to do it are all about software that is not a browser:

• An older desktop application — a design tool, a page-layout program, an accounting package with a logo field — that accepts "an image" and means JPEG.
• A print workflow, where a printer's preflight software may reject an unfamiliar container even when it could technically read it.
• A document template, a form or a portal with a fixed list of accepted extensions.
• An email client that will inline a JPEG attachment and offer a download for a WebP.
• Handing a file to somebody who will double-click it on a machine you do not control.
• A device — a digital frame, a car head unit, a camera's playback mode — with a fixed decoder.

In every one of those cases JPEG is not the better format; it is the compatible one. That is a real and sufficient reason, and it is worth being clear that it is the reason, because "convert to JPG for quality" is a thing people say and it has never been true.

Opening a WebP without converting it

Half the traffic to a page like this is somebody who has been sent a file they cannot open, and the fastest answer is usually not a conversion at all. Drag the file into any browser window and it displays — that works on every operating system and needs nothing installed. Windows Photos has read WebP since 2019 and macOS Preview since Big Sur, so a double-click generally works too.

Converting is for handing the file onward, not for looking at it. If the goal is only to see the picture, the browser you are reading this in has already solved the problem.

What the file loses on the way

The conversion is done from decoded pixels, so the source file's metadata does not come across: no EXIF, no XMP, no ICC profile beyond the colour the browser has already applied, no C2PA manifest. The output is a plain JPEG with a JFIF header and nothing else attached.

That is convenient when the source was a photograph carrying a location, and inconvenient when it was carrying a copyright line you wanted to keep. There is no middle setting here, because re-encoding and metadata preservation are separate operations — the metadata tool is where you look at what a file carries and decide, without touching the picture at all.

Transparency, as above, becomes the background colour. Animation is not preserved: an animated WebP is converted as its first frame, which is a property of every canvas-based converter.

Sizes, and what to expect

A lossy WebP converted to JPEG at quality 92 is usually somewhat larger than the source — often a third to a half larger — because WebP is the more efficient codec and because the JPEG encoder is now preserving WebP's artefacts as if they were detail. A lossless WebP converted to JPEG is dramatically smaller, because a lossless format is becoming a lossy one.

The receipt on this page reports both sizes and the change, so there is no need to guess which of those two cases you are in. If the result is larger than you want, the compressor can aim at an exact ceiling, and the resizer is the bigger lever if the image is also larger in pixels than it needs to be.

All of it runs in this browser tab. The file is decoded, drawn to a canvas, encoded and handed back; no request carries it anywhere, and there is no endpoint on this domain that would accept one.