Lossless PNG optimizing saved 11.4% on transparent icons and 24.8% on photos

My capstone project has a folder of PNG assets: app icons and stickers with soft transparent edges, plus a few photos that someone exported as PNG. A lossless optimizer like oxipng doesn't touch pixels, so it is tempting to expect it to save roughly the same share on every file. On 2026-11-05 I ran it on 12 PNGs from Wikimedia Commons, on an Apple M4 Mac. It saved 11.4% on the 6 transparent images and 24.8% on the 3 photos. That gap is easy to read as oxipng being better at photos. The numbers point somewhere else, and they show what "lossless" actually lets a tool do.

Lossless covers two different jobs

A PNG stores pixels as rows, runs a filter on each row, then compresses the result with deflate. A lossless optimizer can do two things without changing any pixel. It can recompress, which means picking different row filters and squeezing deflate harder. It can also reduce, which means rewriting the image in a cheaper color type when that loses nothing: drop an alpha channel that is 255 everywhere, or switch to a palette when the image has 256 colors or fewer. oxipng has a flag that turns reductions off, so running it twice splits the saving into those two parts.

oxipng -o 4 --strip safe --out a.png in.png
oxipng -o 4 --strip safe --nx --out b.png in.png

The second command only recompresses. The gap between the two outputs is what reductions bought. I also ran zopflipng with -y --filters=01234mepb for comparison. Tool versions were oxipng 10.2.1, pngquant 3.0.3 and zopfli 1.0.3.

Transparent images left nothing to reduce

All 6 transparent images are RGBA with alpha values from 0 to 255, because the edges are antialiased. The total went from 501,130 bytes to 444,175 with reductions on, and to exactly 444,175 with --nx. Reductions contributed 0.0 points. Nothing could be dropped and the color count was too high for a palette, so oxipng could only recompress. On the Afro Mobile Icon the file went from 23,375 to 15,363 bytes, while the decompressed image data stayed at 1,049,088 bytes in both. zopflipng got this group to 429,153 bytes, which is 14.4%.

The photo PNGs were carrying waste

The photo group went from 2,063,192 bytes to 1,685,606 with --nx, which is 18.3%, and to 1,551,821 with reductions, which is 24.8%. So 6.5 of those points came from reductions, and the reason was boring. Two of the three photos are RGBA with alpha at 255 on every pixel. Steve Selvin's portrait became plain RGB, and its decompressed data dropped from 3,258,917 to 2,444,413 bytes before deflate even started. The Alekszej Fedoricsev photo is grayscale and uses only 222 colors, so oxipng turned it into a 222-entry palette with every pixel kept: 407,150 bytes became 167,225, a 58.9% cut on one file. The screenshots looked the same way, 14.5 points from recompression and 9.3 from reductions, and two of those three are also RGBA with alpha at 255.

So the lesson was not "lossless works better on photos". These photos carried data that described nothing. My guess, which I did not test, is that a photo saved as true RGB with thousands of colors would give reductions nothing to remove, the same as these icons. I only had 3 photo PNGs and 2 of them had this alpha problem, so I am not treating 24.8% as a number for photos in general.

What a lossless tool will never do

What it cannot do is remove colors. Quantizing to a palette with pngquant --quality=65-80 cut the transparent group by 77.0% in one step, and running oxipng afterwards added only 2.1 more points. The Afro icon dropped to 23 colors and its decompressed data shrank to 262,656 bytes, about a quarter, because each pixel became one palette index instead of four bytes. Counting the lossless pass first, quantizing still accounted for 86% of the total saving on transparent images and 65% on photos. That step changes pixels, and I did not measure image quality in any way, so I can only say how much smaller the files got.

For everyday batches I use ImgIng https://imging.ai/ in a desktop browser. Browser-side compressors like it broadly work on the same idea of fewer colors plus recompression, though I don't know how it does that internally. When an icon folder barely shrinks after a lossless pass, the optimizer is not broken. Those files have little left to remove without touching pixels, and the real question is whether fewer colors are fine for that asset.

A cheap check before optimizing is to look at the color type and alpha range, then run oxipng once with --nx and once without to see which part a saving came from. One thing I still have not figured out: zopflipng on its own gave different totals than my earlier run on 2026-10-29 with the same parameters. The photo group came out at 1,526,978 bytes this time and 1,624,722 last time, so I treat zopflipng numbers as single runs.

Sample images from Wikimedia Commons: Adaptability icon by Unknown author (CC0); Afro Mobile Icon by Ben plc (public domain); Blue star icon stylized by PrazerCambraia (CC0); Adenosine triphosphate ball-and-stick by FreeCliparts (CC0); Anime girl publicdomainq by oksmith (CC0); Apple cartoon with transparent background by Toby8991 (CC0); Alekszej Fedoricsev by Javelin Bayraktar (CC0); Directiva junto a presidente APPA by JaimeRuix (CC BY-SA 4.0); Steve Selvin by UC Berkeley Public Health (CC BY 4.0); 2011 Talend MDM studio by Copyleft (CC BY-SA 3.0); 2019-06-19 OpenProject by Benoit Soubeyran by Mazuritz (CC BY-SA 4.0); 2020-06-29 Screenshot The Book by Stefan Kühn (CC0).