Converting WebP to PNG

Where WEBP came from, and why it is like this

PNG is the right destination for a WebP more often than JPEG is, and for two reasons that both come down to what WebP is usually carrying.

WebP images saved from web pages are disproportionately interface graphics — logos, icons, illustrations, product shots on white — because those are the images sites bother to optimise. That content has two properties JPEG handles badly: transparency, which JPEG cannot store at all, and hard edges, which JPEG blurs. PNG handles both. It is also lossless, so this conversion adds no new artefacts to whatever the WebP already contains.

Is this conversion lossy?

No. Whatever pixels the WebP decodes to are the pixels the PNG stores, exactly. If the WebP was lossy, its existing artefacts are preserved perfectly — the conversion cannot repair them, but it will not add to them either, and no further degradation can accumulate no matter how many times the PNG is opened and saved.

The cost is size. Expect the PNG to be considerably larger, typically two to five times, and more for photographic content where there is little repetition for a lossless compressor to exploit. For an icon or a logo the difference is trivial. For a full-size photograph it is not.

What happens to metadata, transparency and colour

Transparency survives. This is the main argument for PNG as the target. Both formats have a real alpha channel, so a transparent background stays transparent through the conversion and a logo comes out as a logo rather than as artwork on a black rectangle.

Metadata does not survive. The canvas conversion drops EXIF and any embedded colour profile, as it does in every direction. WebP files saved from web pages usually carry little of either.

Animation does not survive. An animated WebP becomes a single still frame, because a canvas holds one frame at a time. There is no browser-native path from animated WebP to animated PNG, and the converter will not pretend otherwise.

Why people actually need this

Design work, mostly. An asset arrives as WebP — downloaded from a site, exported by a tool, handed over by someone who optimised it — and it needs to go into a design file, a presentation or a document that will not accept it. PNG is the format that everything accepts and that keeps the transparency intact, so it is the natural landing place.

The other situation is archival. Someone has WebP files they want to keep and does not trust a format they cannot open in their own software. Converting to PNG is a reasonable hedge: nothing is lost relative to the WebP, and PNG is about as safe a long-term bet as image formats offer.

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 is a photograph with no transparency and file size matters at all, convert to JPG instead. PNG will store a photograph faithfully and enormously, and the fidelity is not doing any work if the source was already a lossy WebP.

If the WebP is animated and the animation is the point, this conversion is not the tool — you will get one frame. No browser-based converter can do better.

If the file just needs to be smaller for a website, converting away from WebP is going backwards; leave it as WebP and check the compatibility matrix to confirm it renders everywhere you need.