The PNG format

Where it came from

For its first seven years GIF was simply what images on the internet were. Then, at the very end of 1994, Unisys announced it would enforce its patent on the LZW algorithm that GIF used to compress, and developers who had been shipping GIF encoders for free discovered they were expected to pay.

The response was unusually quick. A specification for a replacement was drafted over a matter of weeks on a mailing list, went through several public revisions during 1995, and became a W3C Recommendation in 1996. The design brief was explicit: patent-free compression, exact reproduction of the original pixels, more than 256 colours, and a real alpha channel. The recursive joke in the name — PNG’s Not GIF — tells you how deliberate the whole thing was.

How it compresses

Two stages: a per-scanline filter, then DEFLATE, the same algorithm inside a zip file. The filter is the interesting half. Each row is stored as the difference between its pixels and a prediction made from the pixel to the left, the row above, or a blend of the two, and the encoder picks whichever prediction makes that row’s differences smallest.

On a flat panel of interface grey, all those differences are zero, and zeros compress to essentially nothing. On a photograph the differences are sensor noise, and noise does not compress at all. That one sentence explains almost everything PNG does, in both directions.

What it is good at, and what it is not

It is excellent at screenshots, interface captures, logos, diagrams, charts, line art, pixel art and text on a flat background — anything built from hard edges and regions of identical colour. Its alpha channel gives 256 levels of transparency per pixel, so an antialiased edge composites cleanly onto any background rather than fringing.

It is bad at photographs, and not marginally so. A photograph saved as PNG is commonly five to ten times the size of a JPEG nobody could tell apart from it. Two things account for most slow web pages: a photograph shipped as a PNG, and a photograph shipped four times wider than it is displayed.

Making a PNG smaller, honestly

There are three levers, and this tool has one of them.

Fewer pixels. Halving the width and height quarters the pixel count, and on a lossless format that is the only thing that reliably moves the file size. It is why the quality slider is disabled whenever PNG is the output: there is no quality dial in a lossless encoder to turn.

Fewer colours. Quantising an image down to a 256-entry palette often takes well over half the file away and is invisible on flat graphics. This tool does not do it — there is no palette-reduction step in the pipeline, and claiming otherwise would be the wrong kind of claim to make. pngquant and the many front-ends built on it do exactly this, and for a logo or a diagram that is the tool to reach for.

A different format. WebP and AVIF both compress this material harder than PNG at the same apparent quality, and both keep the transparency.

What to convert it to

WebP for the web. It is the general-purpose answer: much smaller than PNG, keeps the alpha channel, and works in every current browser. Note that what a browser canvas writes is the lossy mode, so it is a re-encode rather than an exact copy.

JPG when the image is photographic and nothing about it needs transparency. Expect a large saving and a flat background wherever the transparency was.

AVIF for the smallest file of all, at the cost of a slower conversion.

Keep the PNG when the pixels have to be exact: source art you will edit again, anything going back into a design tool, or an image whose transparency has to survive untouched.