Bhinish Dhiman
How much PNG to WebP saves, measured on eleven images
Converting PNG to WebP at quality 0.82 in Chromium 153 cut four 1600 × 900 photographs by 92.5% to 96.5%, an 800 px flat logo by 68.7% and a transparent photographic cut-out by 94.2%. Icons went the other way: 64 px grew 32.7%, 32 px 68.5% and 16 px 116%. On flat art it is level with a palette PNG.
The figure everyone quotes for WebP against PNG comes from Google’s study of lossless WebP. Our converter does not write lossless WebP — no browser does from a canvas by default — so that figure does not describe what it produces. Here is what it produces.
The measurement
We prepared eleven PNGs: four 1600 × 900 photographs, a photograph with a soft radial transparency mask, an 800 × 800 flat logo on a background and the same logo on transparency, and a 32-unit tick icon rasterised at 16, 32, 64 and 128 px. Each was converted in headless Chromium 153.0.8010 by the same calls as convertOne() in src/lib/convert/image.ts: createImageBitmap, draw to a canvas, canvas.toBlob('image/webp', 0.82) — 0.82 being the converter’s default. We also re-saved every PNG with libpng at maximum effort, and as a palette PNG, to have a fair baseline for the flat art. Run on 1 October 2026.
| Image | PNG as supplied | PNG optimised | WebP 0.82 | Change vs supplied |
|---|---|---|---|---|
| Photograph A, 1600 × 900 | 1,568,028 B | 698,559 B | 55,498 B | −96.5% |
| Photograph B | 2,327,903 B | 903,228 B | 142,062 B | −93.9% |
| Photograph C | 3,140,320 B | 834,110 B | 148,002 B | −95.3% |
| Photograph D | 2,959,239 B | 932,712 B | 221,848 B | −92.5% |
| Photograph, soft alpha mask | 3,314,685 B | 521,151 B | 192,402 B | −94.2% |
| Flat logo, opaque | 35,475 B | 11,849 B (palette) | 11,108 B | −68.7% |
| Flat logo, transparent | 27,876 B | 11,352 B (palette) | 13,992 B | −49.8% |
| Icon 128 px | 2,097 B | 1,635 B (palette) | 2,042 B | −2.6% |
| Icon 64 px | 1,020 B | 917 B (palette) | 1,354 B | +32.7% |
| Icon 32 px | 559 B | 518 B (palette) | 942 B | +68.5% |
| Icon 16 px | 332 B | 330 B (palette) | 718 B | +116.3% |
Photographs
A photograph stored as PNG is the case the format was never meant for, and the saving is enormous because the starting point is absurd: a 1.5 MB to 3.1 MB file that a lossy encoder can represent in 55 KB to 222 KB. Even against a properly optimised PNG the saving is 76% to 92%. Against JPEG at the same 0.82 setting, WebP was smaller on all four — 55 KB against 105 KB on photograph A — though a quality number is one encoder’s private dial and that is a comparison of two outputs, not of two settings.
Flat art, with an honest baseline
The 68.7% on the logo is real but flatters WebP, because the supplied PNG was an unoptimised export. Against a palette PNG — which is what a PNG optimiser writes for a four-colour graphic, and what our image compressor produces losslessly — WebP is 6% smaller on the opaque logo and 23% larger on the transparent one. On flat graphics the two formats are level, and PNG keeps the hard edges exact.
The icons
Below about 128 px WebP loses, and the loss grows as the image shrinks: the format carries a fixed cost of container and headers that a 332-byte PNG does not have room to amortise. At 16 px the WebP is more than double the PNG. A favicon set should stay PNG, and our favicon generator writes PNG for that reason.
Transparency loses pixels whatever the format
We also asked Chromium for WebP at quality 1.0, which it writes as lossless: the four opaque photographs and the opaque logo decoded back bit-identical to the source. Every image with partial transparency did not. In the soft-masked photograph, 39.77% of pixels differed after the round trip; in the 16 px icon, 8.59%. That is not the WebP encoder. A canvas stores premultiplied alpha, so a half-transparent pixel is rounded on the way in and cannot be recovered on the way out. Any converter that goes through a canvas — ours included — does this to soft edges, at every quality setting, in every output format. For a graphic whose transparency must survive exactly, do not re-encode it through a canvas at all.
What to do with the table
Photographs: convert, and expect more than 90%. Flat graphics: optimise the PNG first and convert only if the result is still too large. Icons under 128 px: leave them. Anything with soft transparency that has to stay exact: leave that too.