Most PNG compression tools don't treat every image the same way. Internally, many of them first try to decide: "is this a photo, or is this a graphic?" Photos get one treatment, graphics get a much more aggressive one. The decision is usually made by sampling pixels and counting how many unique colors show up. Cross a threshold, and the image gets classified as a photo — even if it clearly isn't one.
That classifier is where things go wrong for two extremely common categories of image today: screenshots, and anything generated by an AI image model.
The misclassification, explained
A screenshot of a UI is conceptually simple — mostly flat colors, a handful of shades, some text. You'd expect a tiny unique-color count. But anti-aliasing changes that completely. Every edge of every rendered letter, every rounded corner, every subtle shadow under a card or button gets rendered with dozens of intermediate blended colors to look smooth on screen. Sample enough pixels and the unique-color count climbs well past what a flat graphic should have.
AI-generated images make this worse. Models like Midjourney, ChatGPT's image tool, and Gemini produce soft gradients, ambient lighting, and smooth shading even in stylized or simple-looking outputs. None of that is "photographic" in the traditional sense, but it produces exactly the kind of high unique-color count a naive classifier associates with photos.
Once an image gets bucketed as a "photo," many compressors stop trying to reduce its color palette at all. They fall back to a purely lossless pass — which helps a little, but leaves the vast majority of available savings on the table.
Real before/after numbers
We hit this exact bug while building TinyPixels' compression engine, and fixed it. Here's the same set of files — AI-generated images and a UI icon with soft gradients — compressed before and after the fix, no other settings changed:
| Image | Before fix (PNG) | After fix (PNG) |
|---|---|---|
| AI-generated image (ChatGPT) | -12% | -94% |
| AI-generated image (Gemini) | -39% | -70% |
| AI-generated image (Gemini) | -42% | -67% |
| App icon with gradient | -14% | -74% |
Same files, same quality setting. The only change was correctly handling images the old classifier was routing into the wrong path. A -14% result and a -74% result on the exact same file is the difference between "barely worth running" and "dramatically smaller."
The actual fix
The reliable fix is to stop trying to guess "is this a photo?" at all. Instead: compress the image both ways — a lossless pass, and a palette-quantized pass with proper dithering to avoid banding on gradients — and keep whichever result is actually smaller. This sidesteps the misclassification problem entirely, because no upfront guess is required.
Dithering matters here specifically because of those soft gradients. Reducing a gradient to a small color palette without dithering produces visible banding — hard stripes where there should be a smooth transition. Floyd-Steinberg error diffusion (a long-established dithering technique) spreads the rounding error to neighboring pixels, so the eye perceives a smooth gradient even though the file only contains a couple hundred actual colors.
There's one more wrinkle worth knowing about: transparency. Screenshots and UI exports frequently have transparent or semi-transparent backgrounds, and naive palette reduction can mishandle the alpha channel — clipping soft shadows to fully opaque or fully transparent instead of preserving the gradient. A correct implementation quantizes the RGBA channels together, not just RGB, so translucent edges and drop shadows stay smooth instead of picking up a visible hard edge after compression.
Why this matters more in 2026 than it used to
Five years ago, this misclassification mostly affected a narrow slice of UI screenshots. Today, AI-generated images are everywhere — marketing assets, blog headers, product mockups, social media graphics — and every one of them carries the same anti-aliased, gradient-heavy characteristics that trip up naive photo detection. If your compression tool was built before this content type became common, there's a real chance it's quietly underperforming on a large share of what you're actually compressing today.
What to check on your own files
- Compress a screenshot or AI-generated PNG with your current tool and note the size reduction
- If it's under roughly 30-40%, that's a strong signal it's being treated as a "photo" and skipping palette reduction
- Try the same file as WebP or AVIF — if those shrink it 90%+ while PNG barely moves, the gap confirms the PNG path specifically is underperforming
- Re-test with a tool that always tries quantization rather than guessing first
If you're staying on PNG (for transparency, for compatibility, or because a CMS requires it), this single check can be the difference between a compression tool that's actually working for you and one that's quietly doing almost nothing.
Frequently asked questions
Why do screenshots compress worse than photos?
It's actually the opposite framing — screenshots compress worse than expected because some compressors misclassify them as photographic content. Anti-aliased text and soft gradients push the unique-color count above the threshold those classifiers use, routing the image into a lossless-only path instead of a more aggressive one.
Why are AI-generated images so large as PNG?
AI image generators produce heavy anti-aliasing, soft shadows, and smooth gradients even in simple-looking outputs. That creates thousands of unique colors in a pixel scan — enough to fool a simple "is this a photo?" heuristic, even though there's no real photographic detail.
Does converting to WebP or AVIF avoid this problem entirely?
Largely yes. WebP and AVIF use transform-based lossy encoding rather than a binary quantize-or-don't decision, so they're far less sensitive to this specific misclassification. If you need to stay on PNG specifically, this is exactly the failure mode to watch for.