Convert PNG to WebP

PNG is the format people reach for when an image has to be exact: a logo, an icon, a screenshot, a chart, anything with hard edges or a transparent background. It is lossless, so nothing is ever smudged, and it pays for that with size. On a page carrying twenty interface assets, that bill adds up to the number your performance report is complaining about.

WebP is the answer because it is the only widely supported format that covers both jobs. It compresses photographs about as well as JPG and it has a real alpha channel, so the transparent logo that had to be a PNG and the hero photograph that had to be a JPG can both be WebP. One format instead of two, on a site that already has enough moving parts.

How much you save depends on what the PNG contains, and the range is wide. Screenshots, flat graphics and interface assets typically come down by a quarter to a half. A photograph that somebody saved as a PNG — which happens more often than it should — can lose eighty per cent or more, because PNG is a genuinely poor way to store continuous tone. If your PNGs are large and you are not sure why, that is usually the reason.

WebP has two modes. The lossless one stores every pixel exactly; the lossy one is a still frame of the VP8 codec. The encoder here is called with a quality figure and nothing else, so lossy is what comes out.

For photographs and screenshots that is the mode you would have picked anyway. For a logo or an icon set with one-pixel lines it means a hint of softening its designer can see, so raise the quality for those. Where pixels have to be exact, PNG is the target that guarantees it.

The transparency question, which is the first thing people ask when moving away from PNG, simply does not arise: it is preserved, there is no fill colour to choose, and a cut-out image behaves exactly as it did. That is the practical difference between this conversion and PNG to JPG, where transparency has to be thrown away and filled with something.

Two cases. Favicons — browser support for a WebP favicon is patchy and the file is tiny anyway, so it is not worth the risk. And anything a human will be emailed or asked to open outside a browser, where WebP is still occasionally refused by older desktop software.

Everything else on the site can move. Drop a whole build folder at once: each file converts in your browser with its own progress, nothing is uploaded, files are taken up to a hundred at a time and 100 MB each, and the results come back as a single ZIP with the names intact.

An upscaler writes PNG so that none of the detail it just added is lost, which routinely means 40 MB after a four-times enlargement. That file has no business being served to a visitor, and the saving from WebP is largest exactly where the PNG is largest.

Serve the WebP unless the image has edges that must stay exact. Keep the PNG as the master: it is what any later edit or second upscale should start from, while the WebP is only the copy visitors download.

Replacing images one at a time is not how this is done in practice. Dropping a folder converts them in sequence and hands them back together, and since the work runs on your machine there is no upload for a hundred files and no queue to wait in.

Keep the PNGs. The point of the exercise is to serve WebP where it is understood, and the picture element does that with the PNG as its fallback — which only works if the PNG still exists.

It starts at 82, where the re-encode is invisible on a photograph at normal size. A PNG has never been through a lossy codec, so this is the first generation of loss rather than the second, and it holds up better at a given number than a JPG would.

Raise it into the nineties for interface assets, diagrams and small type, where a single pass shows first. The alpha channel is compressed separately and at full quality by default, so a cut-out keeps crisp edges even when the colour is compressed hard.