A second lossless pass found 0 bytes in iLoveIMG's PNGs and 11.8% in pngquant's

A cheap way to judge a PNG compressor is to run a lossless optimizer over the files it hands back. It can't change pixels, so whatever it still saves is slack the first tool left in filters, deflate settings or palette order. On 2026-11-05 I did this on an Apple M4 Mac with oxipng 10.2.1 at -o 4 --strip safe. The three PNGs that came out of iLoveIMG gave up 0 bytes each. pngquant 3.0.3 at --quality=65-80 left 11.8% on its three photo PNGs: 694,735 bytes went down to 612,968 without one pixel changing.

The samples are 12 PNGs from Wikimedia Commons: 6 transparent icons and illustrations with real alpha from 0 to 255, 3 photos saved as PNG, and 3 screenshots. Two of the three photos are RGBA with alpha at 255 on every pixel, so that group is small and a bit odd. iLoveIMG output exists for only 3 of the 12 (one icon, one illustration, one screenshot), from an earlier batch on 2026-10-29. For batches in a desktop browser there is also the image compression in ImgIng https://imging.ai/ , which follows the same idea of cutting colors first and then recompressing. I did not take its files apart here; this post sticks to the command line and the iLoveIMG files. Each number is one run in exact bytes, and I did not score visual quality.

The check is one extra command

My runs went file by file with the flags above. The folder form below uses the same flags, but I did not run it as written:

mkdir -p re
oxipng -o 4 --strip safe --dir re out/*.png

Then compare sizes file by file. One caveat: --strip safe removes ancillary chunks that do not change how the image renders, so a few of the saved bytes can be metadata rather than better compression. On the Steve Selvin photo it dropped the gAMA chunk, and the non-image chunks went from 50 to 34 bytes. If you only care about compression slack, compare IDAT sizes instead of file sizes. I did not try a run that keeps every chunk.

iLoveIMG left nothing for oxipng

The Afro Mobile Icon (512×512) came back from iLoveIMG as 3,924 bytes, an 8-bit palette with 23 colors and 8 alpha levels. Anime girl (1570×2400) came back as 52,325 bytes with 32 colors and 13 alpha levels, and The Book screenshot (1873×1571) as 459,187 bytes with 256 colors. oxipng saved 0 bytes on all three. I don't know what iLoveIMG runs on its side. The chunks show palette quantization plus a deflate stage that oxipng at level 4 could not improve on. On these three files, a lossless step after it in a build script would have burned CPU and produced identical bytes. Three files are not enough to say the same for everything it returns.

pngquant left 11.8% on the photo PNGs

pngquant's output uses filter type None on every row, in all three groups, while oxipng tries the other filters and may reorder the palette. Alekszej Fedoricsev, a grayscale photo with only 222 colors, went from 131,963 to 100,267 bytes, about a quarter off. Directiva went from 145,573 to 125,889, and Steve Selvin from 417,199 to 386,812. Together that is 11.8% of what pngquant wrote. The other two groups left less: transparent files went from 115,382 to 104,707 and screenshots from 601,760 to 565,455. Against the original files, the second pass adds 2.1 percentage points on transparent images, 4.0 on photos and 1.9 on screenshots.

Whether oxipng's palette reordering helps varies from photo to photo in this set, sometimes in opposite directions, so it is not something to read a rule into.

What a zero does not tell you

A zero means oxipng at -o 4 found nothing. It does not mean the file is as small as it could be. pngquant followed by oxipng was smaller than iLoveIMG on all three shared files: 3,823 against 3,924 bytes for the icon, 50,468 against 52,325 for the illustration, 456,427 against 459,187 for the screenshot. The pixels differ between the two outputs, so that gap comes from different color choices, a lossy decision, and not from slack. Comparing two quantizers fairly needs a quality check, and I have not done one, so I can't say whose 23 colors look better on the icon. oxipng is also not the only lossless pass. On the transparent group, zopflipng after pngquant reached 100,196 bytes against oxipng's 104,707. I never ran zopflipng over the iLoveIMG files, so the zero above is an oxipng number and nothing more.

Before wiring a compressor into a build or picking a web tool for a site's images, run the command above on ten of its outputs. A zero tells you oxipng has nothing to add and only the color and quality question is left. A double-digit saving on one kind of image, like pngquant on these photos, tells you a second pass belongs in the pipeline for that kind.

Sample images from Wikimedia Commons: Afro Mobile Icon by Ben plc (public domain); Anime girl by oksmith (CC0); The Book screenshot by Stefan Kühn (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).