What Happens Inside a PNG File
Open a PNG file and you are looking at a promise. Every pixel you saved will come back exactly as you saved it. That promise is kept by a two stage engine that answers the question how does png compress images. The engine never drops a pixel and never guesses a colour. It works in two passes: a clever prediction step called filtering, then a general purpose squeeze called DEFLATE. Understanding those two steps explains why a flat logo is tiny, why a photograph of the same size is enormous, and what optimisation tools are actually doing when you run them.
Stage One: PNG Filtering Explained
Filtering is prediction. For each horizontal row of pixels the encoder looks at the neighbour to the left, the neighbour above, or both, and guesses what the current pixel should be. It then stores the difference between the guess and the real pixel. A correct guess stores zero. Zero compresses to almost nothing.
The PNG specification gives the encoder five filter types to choose from: None, Sub, Up, Average, and Paeth. None stores the raw pixel value. Sub predicts from the pixel on the left. Up predicts from the pixel directly above. Average takes the mean of left and above. Paeth uses a more sophisticated rule based on the three neighbouring pixels. The encoder tries each filter on each row and picks the one that produces the smallest differences.
Why Flat Colour Vanishes
Take a row of identical background pixels. Every pixel is the same colour. Sub predicts that the current pixel equals the pixel on its left. That prediction is correct every single time. The difference is zero for every pixel after the first. The filtered row becomes a short burst of zeros. DEFLATE then encodes those zeros in a handful of bytes. That is how a solid background compresses to nearly nothing.
Why Photographs Make PNG Files Larger
A photograph never contains two truly identical neighbouring pixels. Digital sensor noise and natural variation mean every pixel differs from its neighbour by a tiny random amount. The Sub filter looks left and predicts the same value. It is wrong. The difference is a small random number. The next pixel produces another small random number. The row is now a stream of near random bytes. DEFLATE sees no repetition and stores almost every byte. That is the whole reason a photograph stored as PNG is around ten times the size of the same photograph as JPEG. The predictor cannot win against sensor noise.
Stage Two: the PNG Compression Algorithm
After filtering, every row of the image is a sequence of bytes that are mostly zero or nearly zero. The png compression algorithm now hands those filtered bytes to DEFLATE, the same compression engine used by ZIP and gzip. DEFLATE works by finding repeated sequences and encoding them with a shorter symbol. A long run of zeros becomes a single instruction that says repeat zero a thousand times. A sequence that never repeats gets stored verbatim.
DEFLATE has no knowledge of images. It sees a stream of bytes. If the filtered bytes contain long runs of the same value, it compresses them hard. If the filtered bytes look like random noise, it stores them almost unchanged. The entire size of the PNG depends on how well filtering prepared the data for DEFLATE.
Why is PNG Lossless
A direct answer to why is png lossless is that neither filtering nor DEFLATE discards information. Filtering stores the difference between a prediction and the real pixel. To reverse the filter, the decoder starts with the first raw pixel and adds back each stored difference, reconstructing the exact original. Every step is reversible by arithmetic. No rounding, no approximation, no discarded frequency data.
JPEG takes the opposite approach. JPEG discards high frequency detail that human vision barely notices, then compresses the remaining data. That is lossy. PNG promised exact pixels, so it can never do that. The trade off is size. A PNG that stores a photograph must keep every sensor noise sample, every subtle texture variation. JPEG throws the subtle variation away and gets a file one tenth the size.
Realistic Size Savings by Technique and Image Type
| Image Type | Lossless Optimisation | Palette Reduction | Format Change To JPEG |
|---|---|---|---|
| UI screenshot | 5 15% | 70 85% | Not recommended: edges ring |
| Logo, icon, line art | 5 15% | 60 80% | Often larger than PNG |
| Photograph | 0 5% | 40 70% | Roughly 90% smaller |
| Illustration with gradient | 5 15% | 40 65% | Banding risk |
What Lossless Optimisation Actually Does
A lossless PNG optimizer like optipng or zopflipng does not change a single pixel. It re runs the same two stage engine more thoroughly. It tries every filter on every row instead of stopping early. It feeds DEFLATE more combinations of compression parameters. It strips metadata chunks like tEXt, iTXt, eXIf, and colour profiles that add bytes but no pixel data. The decoded pixels are identical to the original. Typical saving is 5 to 15 per cent. On an already optimised file the saving can be zero. A correct tool always returns the original file if the new encoding is larger.
Palette Reduction the Lossy Shortcut
If you need the file smaller than lossless optimisation can deliver, you rebuild the image from an adaptive palette of typically 256, 128 or 64 colours. Every pixel now stores 7 or 8 bits instead of 24 or 32. That alone cuts the data in half. But the compounding effect is what matters: thousands of near identical shades collapse into one palette entry, creating exactly the repetition DEFLATE feeds on. The palette entry for that near white background is repeated for every pixel. DEFLATE sees a long run of the same byte and compresses it almost to zero.
Two failure modes exist. Banding in smooth gradients because a soft fade needs many closely spaced colours. Stair step fringes on semi transparent edges because a rounded logo needs enough palette entries for its soft alpha band. A gentler colour count setting fixes both. Palette reduction cannot be undone. Keep the original file and compress a copy.
The Fastest Path to a Smaller File
Strip metadata losslessly first. Then reduce the palette in steps. Then reduce dimensions. Then change format. That order gives the biggest saving with the least visible change. Resize before compressing. Compressing pixels you are about to discard is wasted work and the compressor performs better on the smaller image. For a screenshot or graphic, 500 KB is easy with no visible change. 200 KB is easy on most images. 100 KB may need slight downscaling. Below 50 KB you are either downscaling significantly or switching to JPEG.