Every favicon size, and what each one is for

You paste a single favicon.ico into the site root, the way every guide says to, and something is still wrong. The tab icon is a grey smudge at the top of the window. On an iPhone home screen your logo sits inside a white square with corners you did not draw, rounded off by somebody else. Both faults come from the same cause: one file cannot answer every request, and the file you supplied is being stretched into places it was never drawn for.

Each size in the set was added at a different time by a different company solving its own problem, which is why the pile of numbers looks worse than it is. Sorting them by who asks for them is the whole trick.

The file browsers ask for by name

The ICO format is a container rather than an image. One favicon.ico can hold several bitmaps at different pixel sizes, and the browser picks whichever entry suits the context it is drawing for. That is what the file is for, and it is why a single ICO carrying 16×16, 32×32 and 48×48 still earns its place at the site root.

A browser that arrives at a page with no icon markup at all will still ask the server for /favicon.ico. That behaviour is older than any of the link elements, and every current browser keeps it. It makes the file at the root the one part of the set that works before you have written a line of head markup.

An ICO can hold a 512-pixel entry as well, and some generators write one. Unless the smaller entries are in there too, Windows scales the big one down itself, and the result is the smudge you started with.

The sizes, and where each one lands

The table is the whole reference. The first column is the filename a generator will hand you, and the last column is the one people get wrong most often, because transparency is welcome in a tab and actively harmful on a home screen.

Read the transparency column against the destination rather than on its own. An alpha channel costs you nothing in a tab and is the reason a good logo turns into a dark blob on an iPhone, because there is nothing behind the icon for iOS to composite against.

The home screen icon is drawn by iOS

A 180×180 PNG named apple-touch-icon.png is what iOS picks up when somebody adds your site to their home screen. Safari will scale a different size if that is what it finds, and it rounds the corners into its own squircle before drawing the icon. Two facts, one consequence: the artwork you supply should be a plain square that fills the canvas edge to edge.

Baking rounded corners into the PNG is a common mistake, and an easy one to make, because the icon looks correct in a preview window. iOS rounds it a second time, so the corners you drew sit inside the mask as a faint edge with four pale gaps around them. Transparency is the other one. An iPhone home screen has no white page behind the icon, so transparent pixels arrive as black, and a mark that looked right on a website becomes a dark shape in a black square. Ship it opaque.

An iPad Pro asks for a 167×167 instead, and the same link element can be repeated with a sizes attribute to cover both. Most sites do not bother.

Android crops, so the mark must stay inside

Android launchers do not draw your icon as a square. They draw it inside whatever mask the launcher theme uses — a circle, a rounded square, a teardrop — by scaling the image up and cropping the edges away. The specification sets out what survives that treatment: the important part of the drawing has to fit inside a circle whose diameter is about 80 per cent of the icon's width, centred on the canvas. The outer tenth of the image on each edge can be cut off.

Put numbers on it. A 512×512 maskable file has a safe circle about 410 pixels across, which is a radius of roughly 205 pixels from the centre, and the 51 pixels nearest each edge are the at-risk band. If your mark is a wordmark running from one edge to the other, a Pixel launcher with a circular mask slices the first letter and the last one off, and there is nothing you can do about that afterwards. The fix belongs in the source image: scale the artwork down inside the canvas until it sits within that circle, accept the empty margin, and let the launcher do the cropping it was going to do anyway.

A full-bleed square is still the right answer for the ordinary Android icons, which are not cropped. If you want both, list the file twice in the manifest, once with any and once with maskable; the launchers that crop will take the padded second copy.

An SVG for the pinned tab, where colour is discarded

Safari's pinned tabs do not use your PNG at all. They look for rel="mask-icon", take the SVG it points at, and use the shape as a stencil, painting it in one flat colour that you set with a color attribute in the markup. Everything you drew — gradients, two-tone strokes, your brand colour — is discarded, and the silhouette is what remains.

That makes the mask icon the strictest drawing in the set: a solid shape with no interior detail, on a canvas the artwork fills, because Safari scales it to fit the tab strip rather than padding it. Chrome and Firefox accept an SVG for the ordinary rel="icon" as well and do keep the colours, so one well-made vector serves three places. It cannot cover the smallest size honestly, which is the awkward part of the whole business.

How much markup you actually need

Most current browsers will find /favicon.ico with no markup at all, and iOS will find a 180-pixel PNG at the root called apple-touch-icon.png without being told. The link elements exist for the rest: the browsers that want to be told, the manifest that pulls in the Android pair, and the pinned tab in Safari. Writing them out costs nothing and removes the guesswork.

<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">
<link rel="mask-icon" href="/icon.svg" color="#1b1b1b">

Where the files live matters less than it looks, as long as the paths agree with each other. The site root is the conventional place, because that is where the browsers asking for /favicon.ico by name are already looking.

Why a 512 scaled down to 16 turns to mud

Here is the answer generators tend not to give you. Take the largest file in the set, a 512-pixel square, and ask a browser to draw it in a tab. The browser needs 16 pixels across. That is a reduction by a factor of 32, so a single pixel in the tab icon has to stand in for a 32×32 block of the artwork. Any feature in the drawing narrower than 32 pixels lands inside one target pixel and has to share it with whatever sits beside it.

Run a specific case. Suppose the 512 drawing has a highlight strip 20 pixels wide down its left side. In the tab that strip is 0.625 of a pixel, so the resampler averages it with its neighbours and it becomes a slight lightening of one column. A one-pixel gap between two strokes fares worse: the strokes and the gap merge into a single grey bar. What survives is what was drawn for 16 in the first place, which is one shape, strokes two pixels wide and gaps of at least one.

So the fix is a second drawing rather than a better resampler. Simplifying the mark for the small size means thickening the thin strokes, deleting interior detail, straightening the shallow diagonals, and aligning the edges to the pixel grid instead of to a curve. Done properly, the 32-pixel file is a mild simplification of the master and the 16-pixel file is a different drawing of the same idea. Draw that small version yourself, by hand, and feed it in as the source for the small entries; a resampled 512 is never going to arrive there on its own.

Replacing the file is not enough

Browsers hold on to favicons far longer than they hold other assets. Chrome keeps them in a separate store with its own eviction rules, and a tab will show the old icon for days after the new file is on the server, across reloads and restarts. This is the most common reason a favicon appears not to have worked: it did work, and you are looking at the cached copy of the one before it.

You cannot flush somebody else's cache, so change the thing that is cached. Give the files new names — favicon-2.ico, apple-touch-icon-2.png — or leave the names alone and add a query string to the paths in the markup, which is the smaller edit of the two:

<link rel="icon" href="/favicon.ico?v=2">

Keep the old filenames on the server rather than deleting them. Someone out there has a bookmark pointing at the old path, and a 404 in the tab is a worse look than a stale icon.

What you can safely skip

An ICO is not required. Ship a PNG set and the markup that points at it, and browsers use the PNGs. The ICO earns its keep because of that default request and nothing else, and dropping it has a real cost: whatever still asks by name gets a 404 and draws a blank page icon.

Also worth skipping: the 16-pixel file, which few people would miss on a modern display now that tab icons are drawn at 32 and scaled; the old tile set, with its mstile images and browserconfig.xml, which matters only if you are publishing a Windows store app; and any extra copy of the same drawing at a size the table already covers. The ICO, the apple touch icon and the Android pair carry every context that has real users in it.

The rule I use

Draw one square master at 512, opaque, with nothing important near the edges, and treat it as the source for everything else. Then check the set in the places it will be seen rather than in an editor: the tab at its real size, the bookmarks list, the home screen on a phone, and a Windows shortcut if you ship one. The tab catches the detail problems because it is the smallest of them, and the home screen catches everything to do with colour and transparency.

The habit that saves the most time is the boring one from the caching section: change the filename when the artwork changes, and leave the old files in place. A favicon that changes name is picked up on the first visit, and you never have to explain to somebody that the icon is fine and their browser is being stubborn about it.