Compress PNG Files and Keep Transparency
PNG is the lossless workhorse for graphics — but most PNGs are far larger than they need to be. This guide explains where the bloat comes from and how to remove it without breaking transparency.
Updated 2026-08-06 · ~6 min read
Why PNG files bloat
PNG compression is two-stage: a prediction filter estimates each pixel from its neighbors, then deflate compression stores the differences. Two things determine the final size: how many distinct colors the image has, and how well the filters can predict pixel values.
This explains the classic surprises. A 5-color logo saved from an editor at 32-bit RGBA can weigh more than a photograph, because millions of near-duplicate colors defeat palette optimization. A noisy screenshot with anti-aliased fonts resists filtering. And a photo saved as PNG can be 10× the size of the same photo as JPG — PNG simply is not built for continuous-tone images.
Lossless optimization versus lossy tricks
True PNG optimization is lossless: better filters, better deflate settings, and palette reduction where safe. The pixels out are bit-identical to the pixels in. The savings on editor-exported files are typically 20-60%.
Lossy techniques exist too — color quantization down to 256 colors, or slight posterization. These can halve size again but introduce visible banding on gradients. The decision rule: flat graphics (logos, icons, UI) quantize safely; gradients and photos do not.
The transparency rule
The alpha channel is why you chose PNG over JPG in the first place, and it is also the thing naive compressors destroy. Converting through a pipeline that flattens alpha onto white or black silently ruins cutout logos. The ToolzyLab compressor carries the alpha channel through every step and gives you a checkerboard preview so you can confirm transparency survived before downloading.
If your workflow ends on the web, ask whether you still need PNG at all: WebP supports transparency and typically weighs 25-35% less — see our Image to WebP guide for the conversion path.
A practical optimization workflow
- Start from the cleanest source: export again from your editor at the correct color depth if possible.
- Compress with palette optimization enabled for flat graphics.
- Check the result on a checkerboard — transparency first, then zoom to 100% for banding.
- If size is still excessive for web use, resize dimensions or switch to WebP.
- Keep the original; PNG optimization is safe to repeat, but source loss is not recoverable.
When PNG is the wrong format entirely
- Photographs: PNG stores them losslessly at enormous cost. JPG or WebP are the right containers — try the JPG compressor.
- Icons delivered on the web at very small sizes: a well-made WebP or even inline SVG beats a PNG.
- Anything that will be re-saved repeatedly in JPG by other people: the PNG source is your archive of truth; hand out JPG copies.
Understanding PNG's filter stage
Before deflate compression runs, PNG applies one of five prediction filters to each scanline: none, sub (predict from the left pixel), up (from the pixel above), average, or paeth (a smarter diagonal predictor). The encoder tries to pick the filter that produces the smallest differences, because small differences compress better. This is why two PNGs with identical pixels can differ in size — they made different filter choices.
Re-encoding gives the optimizer a fresh pass at filter selection, which is where a chunk of the typical 20-60% savings comes from on editor-exported files. Editors often write quickly with mediocre filter heuristics; a dedicated optimization pass simply thinks longer about the problem.
Screenshots: the most common PNG job
Screenshots are PNG's natural habitat: sharp text, flat UI colors, and a hard requirement that every glyph stays crisp. Two habits keep screenshot PNGs lean. First, capture at the display's native resolution — upscaling a screenshot after capture doubles bytes and blurs text. Second, crop to the relevant region before sharing; a full 4K screenshot of a single dialog is paying for millions of pixels nobody needs to see.
If a screenshot needs to travel through a system that mangles PNGs (some chat apps recompress images to JPG and smear the text), convert deliberately rather than letting the platform choose: our PNG to JPG guide covers when that trade is worth making.
A web-delivery decision tree
For graphics destined for a website, run this sequence: Is there transparency? If yes, WebP first, PNG as fallback. Flat colors with few distinct hues? PNG with palette optimization will be excellent. Photograph-like continuous tones? Wrong format entirely — move to JPG or WebP. Animated? Neither PNG nor static WebP; that is animated-WebP or GIF territory.
Running each asset through this tree before optimization beats brute-force compression, because choosing the right container is worth more than any setting tweak inside the wrong one.
Transparency audit before you ship
If the PNG heads to a website, test it where it will actually live. Paste it onto both a light and a dark background in a quick HTML page or design tool: halo artifacts from a botched alpha channel are nearly invisible on matching backgrounds and screamingly obvious on contrasting ones. Semi-transparent edges (anti-aliasing against the original background color) are the classic offender — they look fine in the editor and dirty on the live site. If you find halos, the fix is re-exporting from the original with a clean matte, not another compression pass.
Keeping batches consistent
When optimizing an icon set or UI kit, apply identical settings to every file so visual weight stays uniform across the interface. Mixed settings produce icons that subtly differ in edge crispness or saturation depth, which users perceive as sloppiness without being able to name it. Optimize the whole set in one batch run, spot-check three representative icons, and ship them together.
What to do when nothing shrinks enough
Occasionally a PNG refuses to get small enough no matter how you tune it. That is a signal about the content, not the tool: photographic noise or dithering defeats lossless compression by design. The honest options are (1) accept the size because the content genuinely needs it, (2) resize the dimensions so there are fewer noisy pixels to store, or (3) switch formats entirely — WebP lossy handles noisy content far better than PNG lossless ever will. Knowing when to stop optimizing is itself an optimization skill: the last 10% of size reduction usually costs a disproportionate amount of effort and quality.
Common mistakes with this tool
- Quantizing colors on gradient-heavy images and accepting visible banding to save a few KB.
- Assuming any 'compress PNG' tool preserves alpha — many flatten transparency silently.
- Using PNG for photographs and blaming the compressor for the resulting size.
- Deleting the source file after optimization; the original is still needed for future edits.
Frequently asked questions
Is PNG compression lossless?
Proper PNG optimization is fully lossless — output pixels are identical to input pixels. Loss happens only if you deliberately reduce color depth or dimensions.
Why is my logo PNG so large?
Usually it was exported at 32-bit depth with millions of near-duplicate colors. Palette optimization collapses those to the handful of colors actually used.
Will compression break transparency?
Not here — the alpha channel is preserved and previewable on a checkerboard before you download.
PNG or WebP for websites?
WebP is smaller and supports transparency; PNG remains the compatibility choice for older software and print pipelines.