How PNG Compression Works: Deflate, Filters, and File Size

A deep dive into the PNG compression pipeline — prediction filters, DEFLATE, and the decisions that determine your final file size.

PNG is not one thing — it is a pipeline

When people say "compress a PNG", they usually mean reduce its file size without degrading the image. But PNG compression is not a single operation — it is a two-stage pipeline, and the decisions made at each stage compound to determine the final file size. Understanding both stages explains why two PNG files containing visually identical images can differ in size by 50% or more.

Stage 1: Prediction filtering

Before any compression is applied, PNG runs the raw pixel data through a prediction filter. The idea is simple: instead of compressing the actual pixel values, compress the difference between each pixel and a predicted value based on its neighbours.

Why? Because pixel differences cluster near zero. A gradient background might have RGB values like (120, 130), (121, 130), (122, 130) — the actual values are in the hundreds, but the differences are 1, 1, 1. Small, repeated numbers compress far better than large, varied ones.

The PNG specification defines five filter types, applied independently to each row of pixels:

  • None: No filtering — raw pixel values are passed to the compressor.
  • Sub: Each byte is stored as its difference from the byte one pixel to the left.
  • Up: Each byte is stored as its difference from the corresponding byte in the row above.
  • Average: Each byte is stored as its difference from the average of the left and above bytes.
  • Paeth: Uses a linear predictor (named after Alan Paeth) that picks the best of left, above, and upper-left as the prediction.

The encoder can choose a different filter for every single row. The optimal choice depends on the content of that row. Many encoders use a fixed strategy (such as always using Paeth) or a heuristic. A dedicated PNG optimiser like zopflipng or a good online tool will try multiple filter combinations and keep the one that produces the smallest output after compression.

Stage 2: DEFLATE compression

After filtering, the data is compressed using DEFLATE — the same algorithm used in zip files and gzip. DEFLATE is itself a two-layer algorithm:

LZ77: Scans the data for repeated byte sequences. When a sequence that appeared earlier in the stream is encountered again, it is replaced with a back-reference: a (distance, length) pair pointing to the earlier occurrence. This exploits structural redundancy across the image.

Huffman coding: Assigns variable-length binary codes to the symbols (literal byte values and back-reference tokens) based on their frequency. Common symbols get short codes; rare symbols get long codes. This exploits statistical redundancy.

DEFLATE has a compression level setting (1–9 in most implementations) that controls the trade-off between CPU time and compression ratio. Level 1 uses a fast, greedy matching strategy. Level 9 performs an exhaustive search for the best possible matches. For web images, the difference in file size between level 6 (the default in many encoders) and level 9 is typically 2–8%. Not huge, but free savings — the decompressed output is identical either way.

Some advanced optimisers go further and use Zopfli, a DEFLATE-compatible compressor that treats finding the optimal encoding as a shortest-path problem. Zopfli can take 100× longer than standard DEFLATE but typically achieves 3–8% better compression than level 9 zlib on PNG data. The output is fully compatible with any PNG decoder.

What determines PNG file size?

Given this pipeline, several factors drive file size:

  • Image dimensions: More pixels means more data before compression.
  • Colour depth: A 24-bit RGB PNG (8 bits per channel) stores three times as much data per pixel as an 8-bit palette PNG. For images with 256 or fewer distinct colours, converting to palette mode (PNG-8) is a lossless operation that can halve file size.
  • Image content: Flat colours, gradients, and geometric shapes compress extremely well. Natural photographs compress poorly because their pixel values are information-dense and unpredictable.
  • Filter choices: Suboptimal filter selection can increase file size by 10–20% even with perfect DEFLATE compression downstream.
  • Compression level and algorithm: Encoding with zlib level 6 instead of level 9 or Zopfli leaves measurable savings on the table.
  • Metadata chunks: PNG files can embed arbitrary metadata (text chunks, EXIF data, creation software names, colour profiles). These add bytes that are irrelevant to the image content and can safely be stripped for web delivery.

Optimising a PNG without changing its appearance

A lossless PNG optimisation pass typically does the following:

  1. Try all five filter types (or an adaptive strategy) for each row and select the best.
  2. Recompress the filtered data at maximum DEFLATE level (or Zopfli).
  3. Strip non-essential metadata chunks.
  4. Optionally: test whether converting to an 8-bit palette produces the same visual result (only safe for images with ≤ 256 colours).
  5. Optionally: test whether lossless WebP produces a smaller file (WebP lossless uses a more efficient compression pipeline and typically beats PNG by 15–25%).

The result is a file that decompresses to exactly the same pixels as the input — no quality loss, no visual change, just a smaller container.

Want to see this in action? Drop your PNG files into compressanimage.com for instant lossless optimisation — no uploads, no accounts, no quality loss.

PNGDEFLATEcompressionfilters

Ready to compress your images without losing quality?

Try the free tool →