PNG optimization with palette and quantization

Why PNG files are large

PNG is a lossless format built around the DEFLATE data stream, and it has a structural quirk that drives up file size on the web: many PNG files are saved as 24-bit truecolour or 32-bit RGBA, meaning every pixel stores a full colour value even when the image only actually uses a few dozen distinct colours. A small icon or logo with 30 unique colours stored as a 32-bit RGBA PNG still carries red, green, blue, and alpha bytes for every pixel. Most of that data is redundant.

So there are two independent levers for shrinking a PNG: reduce the *number of colours* stored per pixel (called palette reduction or quantisation), and then compress the already-smaller data stream harder. The first lever gives the biggest win for flat graphics; the second helps everything.

Quantizing to a palette

The core optimisation is converting a truecolour or RGBA PNG into an indexed 8-bit palette PNG. Instead of storing a full colour per pixel, the file stores an index into a palette of up to 256 colours, so each pixel becomes a single byte. For an image that genuinely uses under 256 colours, this can cut the file dramatically, and because the palette approach is a lossy transformation (colours get mapped or dithered), the savings for suitable content often reach 60 to 80% compared to the equivalent 24-bit PNG.

A 256-colour indexed format is a poor fit for content that is inherently photo-like. Photographs have smooth gradients spanning thousands of colours, and crushing them to 256 indexed colours produces obvious banding. Quantisation suits graphics, logos, simple illustrations, and UI assets, exactly the content that is glad to be in PNG in the first place. Alpha transparency is preserved: the indexed format keeps an alpha channel, and good quantisers work in a premultiplied-alpha colour space so transparent pixels do not get weird halos.

A practical pipeline

The standard command-line tool is pngquant, which selects the palette using a modified Median Cut algorithm with dithering to hide banding, and is batchable. A typical invocation is:

pngquant --quality=65-80 --speed 4 input.png -o output.png

The --quality range tells pngquant the acceptable output quality: it auto-finds the fewest colours that meet the maximum, and if it cannot reach the minimum it refuses to write the file rather than shipping a visibly degraded image. --speed 4 is the balanced default; lower values search for a better palette at greater processing cost. After quantisation, a second lossless pass such as oxipng or optipng optimises the DEFLATE streams and removes unused palette entries, which typically squeezes out more bytes for free.

A working rule of thumb is to reserve the technique for images that are not photographs, then check the output at 100% zoom for banding or edge fringing before you commit it. Neither palette reduction nor the lossless second pass alters the rendered pixels beyond the mapping you already accepted, so a short visual check is usually all that is required. When colours or edges look wrong, back the quality down or skip the tool for that asset and use the format-choice guidance to consider WebP or AVIF instead.