Converting WebP to JPG

Where WEBP came from, and why it is like this

Almost nobody chooses WebP. They acquire it: an image saved from a web page arrives as .webp because that is what the site served, and then it will not open in whatever the person uses to look at images. Browsers all display WebP; the software people actually edit images in has been slower, and plenty of installed applications — older Photoshop versions, most default desktop viewers on Windows, a lot of print and publishing software — will simply refuse the file.

So this conversion is rarely about compression. It is about getting an image out of a format the web chose and into one everything can read, which is still JPEG, thirty-odd years on.

Is this conversion lossy?

Yes, and the amount depends entirely on which kind of WebP you have — and you cannot tell by looking at the filename. A lossless WebP converted to JPEG takes its first lossy hit here, and at a high quality setting it will be visually identical. A lossy WebP converted to JPEG is a second generation, with the same compounding caveat as any re-encode.

The one thing worth watching is that WebP's smoothing and JPEG's blocking are different kinds of artefact, so a re-encode does not simply deepen the existing damage — it adds a new pattern. Flat areas that WebP had smoothed can pick up JPEG's faint block edges. Usually invisible; occasionally not, on gradients.

What happens to metadata, transparency and colour

Transparency is lost, and this is the trap. WebP supports an alpha channel and JPEG does not. If the WebP you saved from a web page has a transparent background — logos and icons very often do — the transparent area has to become a solid colour, and in a canvas conversion it becomes black rather than white. A logo that looked fine on the page comes out as artwork in a black box.

If that is what you are converting, convert to PNG instead. It is the same click and it keeps the transparency.

Animation is lost. WebP can hold an animated sequence, and JPEG cannot hold anything but a single frame. An animated WebP converted here becomes one still image.

Metadata is lost, as with every canvas conversion — though a WebP saved from a web page rarely has much worth keeping.

Why people actually need this

The concrete situation is nearly always the same one: someone saved an image from a website, tried to attach it to something or open it in an editor, and was told the file type is not supported. Upload forms are the most common wall — a job application portal, an insurance claim, a school system — because their accepted-formats list was written before WebP existed and nobody has updated it.

The second situation is a printer. Print workflows are conservative and WebP has essentially no presence in them, so an image destined for anything physical has to become JPEG, PNG or PDF first.

What we measured

This conversion was run end to end before this page was written. Not "should work" — run, with the output checked:

And the ceilings measured for Image converter, the tool that performs it, on the hardware described on the limits page:

Not tested

The page also refuses files above 50 MB before it starts, which is a guard written into the tool rather than something the browser imposes. Why those are different.

When something else is the better answer

If the image has transparency, convert it to PNG instead of JPG. This is the single most common mistake on this conversion and it is entirely avoidable.

If the image is a screenshot, a diagram or anything containing text, PNG is again the better target — JPEG's artefacts are at their most visible on exactly that content.

If the image is going into a document, converting straight to PDF avoids the intermediate step and the compatibility question with it.