Compare App Icons and Favicons Across Every Export Size

The icon that breaks is never the one you checked

An icon export pipeline typically produces a dozen or more sizes from one source — 16×16 and 32×32 favicons, 180×180 for iOS home screens, 512×512 and 1024×1024 for app store listings, plus whatever an Android adaptive-icon or PWA manifest wants. Nobody visually checks all of them by eye every release, and the ones that get skipped are exactly the small sizes where problems actually show up: fine detail that reads fine at 512px turns into a smudge at 16px, and a resizing tool’s automatic sharpening can shift colors just enough to look off next to the brand palette everywhere else.

The reliable check isn’t “does the icon look right” at any one size — it’s “does the small version still look like the same icon,” which is a comparison, not a glance.

Compare each export against a reference render

Render your source icon down to each target size yourself with a known-good method (a design tool’s export, or a consistent resize algorithm), and treat that as your reference. Compare it against whatever your actual build pipeline produced at the same size, using DiffALL’s image comparison.

This catches the class of bug that’s easy to introduce silently: a build script’s icon generation step gets swapped for a different library, a caching layer serves a stale export, or a manifest points at the wrong file for one specific size. The icon still “looks like your icon” to a glance, but it’s not byte-identical to what your reference render produced, and a comparison catches that where eyeballing won’t.

What actually differs at small sizes

Detail that survives at 512px and disappears at 16px. Fine strokes, small text, or thin gaps between elements — anything under roughly 2px at the target size gets lost or merged in downscaling. A heatmap comparison between your 512px source and a naive 16px resize will show broad, diffuse differences across exactly the areas with fine detail, which is your signal to simplify the icon for small sizes rather than relying on a generic resize.

Edge aliasing on rounded corners and circles. Different resize algorithms handle curved edges differently at small sizes — one produces a slightly softer edge, another a harder one. This shows as a thin band right along every curved edge in the difference map, and it’s usually not worth chasing unless it’s visually obvious at the actual display size.

Color drift from automatic sharpening. Some export pipelines apply sharpening on downscale, which can shift saturation slightly. If your brand color needs to be exact at every size (it usually does for a logo), compare a sharpened export against an unsharpened one — a uniform color-only difference across the whole icon, with no structural difference, is exactly that.

Set a baseline once, then just diff against it

Keep one known-good export per size as your reference set. Every time the icon changes — new artwork, a new export tool, a dependency bump in your build pipeline — regenerate and compare against that reference instead of re-checking everything by eye. A high similarity score means the pipeline is still doing what it did last time; a low one at exactly one size tells you precisely which step to look at, instead of a vague sense that “the icon looks different somehow.”

Try it

Compare images → — compare each exported size against a reference render at that same size, not against the full-resolution source, since that’s the comparison that actually reflects what a user sees.