I build png.now, a toolkit focused on PNG files, and the most common question we get is some version of "how do I make this smaller without making it worse?" This explainer covers how PNG compression works, where the waste usually hides, and when the right answer is a different format.

How PNG compression works, briefly

PNG is lossless. Every pixel you put in comes back out exactly. It gets its size savings in two stages:

1. Filtering. Each row of pixels is transformed using one of five filters, which describe each pixel relative to its neighbours. On smooth or repetitive images, this turns the data into lots of small, similar numbers.
2. DEFLATE compression. The filtered data is compressed with DEFLATE, the same algorithm used in ZIP files.

Because both steps have choices, such as which filter for which row and how hard DEFLATE should try, two PNGs containing identical pixels can differ a lot in file size. Many export tools pick fast settings rather than small ones.

Where the waste usually hides

1. The wrong colour type and bit depth

PNG supports several colour types: greyscale, greyscale with alpha, truecolour (RGB), truecolour with alpha (RGBA), and indexed colour (a palette of up to 256 colours). It also supports bit depths from 1 to 16 bits per channel.

A logo with eight flat colours saved as 16-bit RGBA stores far more information per pixel than it needs. The same image as an 8-bit palette PNG holds exactly the same pixels in a fraction of the space. Common offenders:

• Screenshots saved with an alpha channel that is fully opaque everywhere
• 16-bit exports from design or scientific tools when 8 bits would look identical
• Greyscale images stored as RGB

2. Metadata and extra chunks

A PNG file is a series of chunks. The essential ones hold the image header, palette and pixel data. Optional chunks can hold text (tEXt, iTXt, zTXt), EXIF data (eXIf), embedded colour profiles (iCCP), gamma and colour information, timestamps, and application-specific data.

Design tools sometimes write large chunks of editor data into exported PNGs. An embedded ICC profile can add a noticeable amount on a small icon. For web graphics, most of this can go. For print or colour-critical work, you may want to keep the colour profile.

3. Non-optimized compression

Even with the right colour type and no extra chunks, the default compression from many apps leaves savings on the table. Lossless optimizers try different filter strategies and stronger DEFLATE settings to find the smallest encoding of the same pixels. Well-known open-source tools include oxipng and optipng. The result is pixel-for-pixel identical, just smaller.

4. Photographic content

This is the case where PNG genuinely is the wrong format. Photos have noise and fine gradients that filtering and DEFLATE cannot compress well. No amount of lossless optimization will get a photo PNG down to JPG or WebP sizes.

Lossless vs. lossy PNG optimization

There are two families of PNG optimization, and it is worth being clear which one you are using.

Lossless optimization keeps every pixel identical. It changes colour type when that is safe, strips unneeded chunks, and recompresses. Savings vary from almost nothing to quite a lot, depending on how the file was originally saved.

Palette quantization converts a truecolour image into an 8-bit palette of up to 256 colours, often with alpha preserved. Tools like pngquant do this. It is technically lossy, because colours are merged, but on flat graphics, icons and many screenshots, the difference is very hard to see, and the file can shrink dramatically. On photos or smooth gradients, you may see banding.

The safe workflow: try lossless first. If the file is still too large and the image is a graphic rather than a photo, try a palette version and compare them side by side.

When to leave PNG behind

PNG is the right choice for screenshots with text, logos, icons, line art, UI assets, and anything that needs exact pixels or transparency in a widely supported format. It is the wrong choice for:

• Photos on the web: use JPG, WebP or AVIF.
• Large graphics where size matters most: WebP lossless is usually smaller than an optimized PNG of the same image, and WebP and AVIF both support transparency.
• Animations: APNG works in modern browsers, but for long or complex animations a video format is usually much smaller.

When converting, keep in mind that transparency only survives if the destination supports it. JPG does not, so transparent areas get filled with a background colour.

A practical checklist

1. Is it a photo? Convert to JPG, WebP or AVIF.
2. Is the alpha channel actually used? If not, drop it.
3. Does it need more than 256 colours? If not, try a palette PNG.
4. Does it need 16 bits per channel? For the web, almost never.
5. What metadata is inside? Inspect the chunks and strip what you do not need.
6. Run a lossless optimizer.
7. Compare the result with the original at 100% zoom before replacing it.

How we approach this at png.now

We built png.now around that checklist rather than around a single "compress" button. It has a Lossless PNG Optimizer, a PNG-8 Palette Optimizer, a Chunk Inspector that shows what is inside the file, a Metadata Viewer & Remover, a Transparency Editor, and a PNG Image Diff for checking that an optimized file still matches. When PNG is the wrong format, the converter turns PNG into JPG, WebP, AVIF, PDF, GIF, BMP, TIFF and ICO, preserving transparency where the destination supports it.

Whatever tool you use, the order matters: inspect first, change the colour type and metadata second, recompress last, and always compare. If you want to see what is hiding in one of your own PNGs, the chunk inspector on png.now is a quick place to start.