What favicon sizes do you actually need?

The six that are actually used

Favicon advice has accumulated for twenty-five years and most of what circulates is describing browsers nobody runs. The current list is short.

**16 and 32 pixels** are the browser tab and the bookmark bar. Sixteen is what a tab shows at standard density; thirty-two is what it shows on a high-DPI display and what appears in bookmarks and history. These two carry almost all of the visible use.

**48 pixels** is the Windows site icon, used when a page is pinned or shown in certain shell surfaces. Small cost, occasionally visible.

**180 pixels** is `apple-touch-icon`, used when someone adds your site to an iOS home screen. **192 and 512** are the Android and PWA sizes, referenced from a web manifest: 192 for the home screen icon and 512 for the splash screen and install prompt. Those three are what make a site look deliberate when someone saves it.

Why 16 pixels is a design problem, not a scaling problem

The most common mistake is generating every size from one image and assuming the small ones will be fine. They will not, and the reason is that sixteen pixels is fewer pixels than most people picture.

A logo with a wordmark becomes an unreadable smear. Fine strokes disappear entirely or alias into grey mush. Anything with more than about three distinct shapes reads as noise. A gradient becomes a flat blob. At that size you are not shrinking a logo, you are designing a different mark that happens to be related to it.

The practical rule is to design the small sizes as their own artwork: one shape, one or two colours, heavy strokes, and generous internal spacing. Most strong favicons are a single letter, a simple glyph, or a monogram — and they are recognisable precisely because they gave up on reproducing the full logo.

Test at actual size rather than zoomed in. An icon that looks fine at 400 percent in a design tool routinely falls apart in a tab, and the tab is the only place it will ever be seen.

Where .ico still matters, and where it does not

The `.ico` format is a Windows container that can hold several sizes in one file, and it is the reason `/favicon.ico` became a convention. Every browser still requests that path automatically, whether or not you reference it.

That automatic request is the whole argument for still having one. Without a file there, every visit generates a 404 in your logs — harmless but noisy — and a few older surfaces will show nothing. A single `.ico` containing 16, 32 and 48 covers it.

What has changed is that it is no longer where the interesting sizes live. Modern browsers prefer a PNG referenced explicitly by a `<link rel="icon">` tag, and PNG handles transparency and high-DPI rendering better than the legacy container does. So the sensible arrangement is a PNG set for everything that matters plus an `.ico` at the root as a fallback nobody has to think about.

SVG favicons are supported in current Chrome and Firefox and are genuinely useful for one thing: they can respond to the browser's dark mode with a media query inside the file, so a dark logo can invert against a dark tab strip. Safari support has historically lagged, so an SVG belongs alongside PNGs rather than instead of them.

The markup, and the file most sites get wrong

The minimum that works everywhere is four lines: an `.ico` at the root that needs no tag, a PNG icon link, an `apple-touch-icon` link, and a manifest link.

`apple-touch-icon` is the one most sites get wrong, and the failure is specific. iOS does not use transparency — it composites the icon onto a background, and where your PNG is transparent it will use black. A logo designed on a transparent canvas therefore arrives on the home screen as a dark square with a floating mark in it. Flatten that one file onto a solid background deliberately, and it will look like an app icon rather than an accident.

iOS also applies its own rounded-corner mask, so do not round the corners yourself — you will get a rounded shape inside a rounded mask with a visible gap. Supply a full-bleed square and let the platform cut it.

The Android sizes come from the web manifest rather than a link tag, listed under `icons` with their sizes and types. A manifest that names 192 and 512 is what makes the install prompt appear correctly; one that omits 512 tends to produce a stretched or missing splash screen.

Getting it consistent

Generate every size from a single high-resolution square master rather than from whatever file was to hand. Mixed sources are how a site ends up with a slightly different crop at 32 than at 180, which nobody notices individually and which collectively reads as sloppy.

Start from at least 512 pixels square. Upscaling to reach 512 from a smaller original produces soft edges at exactly the size most likely to appear large on a splash screen.

Decide transparency per file rather than globally. Tab icons benefit from it, because they sit on a browser chrome colour you do not control and which changes with the user's theme. `apple-touch-icon` must not have it. That single distinction accounts for most home-screen icons that look broken.

And clear the cache before concluding it is wrong. Browsers cache favicons unusually aggressively — often beyond a normal hard refresh, and sometimes until the profile is restarted. An icon that looks stale after a change has very often deployed correctly, and testing in a private window is faster than debugging something that already works.

Questions