PNG vs WebP

This is not a comparison of two formats with different strengths. WebP has a real alpha channel, a lossless mode that reproduces every pixel exactly, and a lossy mode PNG never had — so there is no capability PNG holds that WebP lacks.

What changes is the size. Lossless WebP is typically a quarter to a half smaller than the same PNG with nothing given up at all, and lossy WebP goes far below that for images where a small imperceptible loss is acceptable. On a site carrying twenty interface assets, that is the whole difference between a fast first impression and a slow one.

The phrase gets used loosely enough to be worth stating plainly. WebP’s lossless mode reproduces every pixel exactly — not "visually lossless", not "near-lossless". A comparison tool finds no differences at all, because there are none.

What changes is only how compactly those pixels are described, using techniques PNG’s 1996 compression did not have. That is why the choice for a logo or an icon set is not between quality and size: lossless WebP is the same image in fewer bytes, and the only thing being weighed is compatibility.

Because of everywhere that is not a browser. Every current browser has read WebP for years, including Safari, so on a web page it is settled. Outside one, support is patchy in exactly the places that matter socially: email clients, older phone galleries, chat applications, some content-management upload forms, plenty of desktop software, and printing workflows.

The practical rule that follows is about the destination rather than the image. Serving on a web page: WebP. Attaching to an email, handing to a client, uploading to somebody else’s system, sending to a printer: PNG, every time. Nobody has ever been thanked for emailing a WebP.

A favicon should not be WebP — browser support for it in that role is patchy and inconsistent, the file is tiny anyway, and the risk is not worth the two kilobytes. PNG or ICO, as it has always been.

The other exception is any image a visitor is meant to download and use: a press photograph, a logo pack, a template, a diagram somebody will paste into a document. Deliver those as PNG regardless of what the page itself displays, because the recipient’s software is unknown and their tolerance for an unfamiliar extension is low.

The saving is not uniform, and claiming it is would be dishonest. On screenshots, photographs stored as PNG and detailed interface assets, lossless WebP wins clearly. On very small flat graphics — a two-colour bullet, a spacer, a simple icon of a few hundred bytes — PNG is already close to the floor and WebP can come out slightly larger.

This matters when a build pipeline converts an entire asset folder and the total barely moves. Convert five representative files of your own and compare the byte counts before rewriting a build. It takes ten minutes and it beats any general rule, including this one.

The standard way to serve WebP is a picture element with a WebP source and a PNG fallback, which only works if the PNG still exists. Converting an asset folder in place is the mistake to avoid.

Keep the originals in version control as the master, generate WebP as a build step, and the site gets the smaller files while the next format — whatever it turns out to be — can still be generated from a lossless source. An asset library that has been converted in place can only ever produce copies of a copy.

For photographs, AVIF is usually smaller again than WebP, sometimes substantially. For flat interface graphics it is frequently larger, and its encoding is much slower.

So the sensible arrangement is not to pick one successor. Serve AVIF first, WebP second, PNG as the fallback, and let each browser take the best it understands. If that is more pipeline than the site justifies, WebP alone with PNG behind it captures most of the benefit for a fraction of the complexity.