Icon checklists routinely name twenty or more files. Most of that list is historical — sizes that mattered for browsers and devices that have since been replaced — and a modern site needs a handful.
The reason to trim it is not laziness. Every extra file is one more thing to regenerate when the logo changes, and a set that is tedious to update is a set that drifts out of date.
What is the short list?
Four entries, one of which does several jobs.
| File | Size | Used by |
|---|---|---|
| SVG icon | scalable | modern browsers, any size |
| PNG icon | 32 × 32 | tabs, bookmarks, fallback |
| Touch icon | 180 × 180 | added to a phone home screen |
| Manifest icons | 192 and 512 | installed web apps |
The scalable file is the one that changed the arithmetic. A browser that accepts it renders the icon crisply at any size, which removes the reason most of the intermediate sizes ever existed.
The small PNG remains because not everything reads the scalable form, and because some contexts want a raster. Between those two, the tab icon is covered everywhere.
Why does the old format hold several sizes?
Because it was designed as a container. The traditional icon file can hold multiple resolutions in one file, and the system picks the closest match — which is how a single file served a 16-pixel tab and a larger desktop shortcut.
That was genuinely useful when browsers requested a fixed filename from the site root and nothing else. It is still supported, and it is no longer necessary when the page can point at exactly the icons it has.
Keeping one at the root does no harm and catches anything that still looks for it without asking the page.
What makes a good icon at 32 pixels?
Removal. An icon at that size has room for one shape, and a logo containing a wordmark, a symbol and a tagline has to lose two of the three.
The usual answer is the symbol alone, or a single letter set in the brand’s typeface. Both survive being tiny; a detailed illustration does not, and reducing it produces a smudge that reads as a generic mark.
Contrast matters more than colour here, because the icon sits against a browser interface that may be light or dark. An icon that relies on a white background disappears in a dark tab strip, which is a reason to give the mark its own filled shape rather than letting the page background show through.
How do app icons differ?
They get masked. Mobile platforms crop icons into their own shape — a rounded superellipse on one, a shape the user may be able to choose on the other — so an icon is drawn into a square and displayed as something else.
That makes a safe zone necessary. On the platform with variable shapes, the outer band of the canvas may be cropped away entirely, so the mark has to sit within the central region and the corners have to be expendable.
Supplying a pre-rounded icon is the classic mistake. The system applies its own mask on top, and the result is a rounded shape inside another rounded shape with a visible gap.
When should you regenerate the set?
Whenever the mark changes, and from one source. Generating every size from a single scalable master keeps them consistent; editing them individually guarantees that one of them stays wrong for years.
The other trigger is a platform adding a requirement, which happens occasionally and rarely urgently. An installed web app manifest wanting a maskable variant is the recent example.
Version the filenames or set the cache headers deliberately. Icons are cached hard by browsers, so a replaced icon at the same path can take a long time to appear.
What format should each one be?
Scalable vector where it is accepted, PNG everywhere else. Vector stays sharp at every size and stays small, which is exactly what an icon needs — and it fails only where something insists on a raster.
PNG is the right raster choice because it keeps hard edges and supports transparency. A JPEG icon is a poor idea for both reasons: it blurs the edges that make a small mark legible, and it cannot have a transparent background at all.
Transparency itself needs a decision rather than a default. An icon with a transparent background adapts to whatever sits behind it and disappears when that background is close to the mark’s own colour, which is why most app icons are drawn on a filled shape instead.
Questions people ask
How large should the source be? Draw at whatever size is comfortable and export down. Anything drawn at 32 pixels is drawn too small to think in.
Do I still need a root icon file? It costs one file and catches old requests. Keep it.
Can the scalable icon be animated? Some browsers honour it and most do not. Not worth relying on.
Should the icon match the logo exactly? It should be recognisably the same mark, simplified. Exact matching is what makes it illegible.
Does a dark mode icon variant work? The scalable format can respond to the colour scheme, which is one more argument for using it.
Generate from one master. Favicon sizes covers the browser set, the Apple touch icon size handles the home screen, and app icon sizes lists what the mobile platforms ask for including the masked safe area.