Your Favicon Is 16 Pixels Wide. Design For That.

Open any browser and look at your tab strip. Some icons you identify instantly. Others are indistinct grey smudges you can only tell apart by position.

The difference is almost never budget or design skill. It is whether someone designed for 16 pixels or shrank something designed for 500.

The constraint

A favicon displays in a space roughly the size of a lowercase letter. On a standard display that is 16 CSS pixels; on a high-density screen it is rendered at 32 device pixels, which is why you ship a 32 pixel file.

Sixteen pixels across gives you about a dozen distinguishable regions. That is enough for one shape. It is not enough for anything else.

Things that reliably fail at this size:

• Wordmarks longer than two characters. Three letters at 16 pixels is four pixels each.
• Thin strokes. A 2 px line in a 512 px design is 0.06 px at 16. It disappears.
• Gradients. They average out to one flat mid-tone.
• Photographs. Always.
• Outlines around shapes. The outline and the fill merge.
• Any logo with internal detail. Detail becomes noise, and noise becomes grey.

All of these look completely fine in a generator preview at 200 pixels, which is why the problem survives review and only appears once the site is live.

What works

• One bold shape. A single letter, a simple geometric mark, a distinctive silhouette.
• Exactly two colours, with high contrast between them.
• A filled background rather than transparency.
• Generous weight. Strokes that look too heavy at full size are usually about right.

Most companies with a detailed logo ship a simplified favicon rather than a shrunken one. That is the correct move, not a compromise, and it is what the tab strip rewards.

Why the background must be filled

A transparent favicon sits on whatever the browser chrome happens to be, and that changes with the user’s theme.

A dark icon on a dark tab strip disappears completely. A light icon vanishes in light mode. Since you cannot control which theme the viewer uses, transparency means accepting that your icon is invisible to roughly half your audience.

Filling the background with a solid colour solves this in one step, which is why most well-made favicons are a coloured square or circle with a mark on top. It also gives the icon a defined edge, helping it read as a distinct object rather than merging into its neighbours.

If you want a genuinely theme-aware icon, an SVG favicon can carry a prefers-color-scheme media query internally and swap colours. Support is good in current browsers and absent in older ones, so it supplements the PNGs rather than replacing them.

The file set you actually need

Favicon advice has not caught up with browsers. Generators still produce twenty files and fifteen lines of markup covering devices that stopped shipping a decade ago.

What is genuinely useful:

• 32 × 32 PNG for the browser tab and bookmarks
• 180 × 180 PNG as the Apple touch icon, for iOS home screens
• 192 × 192 and 512 × 512 PNG referenced from the web manifest, for Android and installed web apps
• An SVG, optionally, for browsers that support it

Four files, four lines of markup:

<link rel="icon" href="/icon-32.png?v=1" sizes="32x32">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">
<meta name="theme-color" content="#2563eb">

Anything beyond this is maintenance for an audience that no longer exists.

Do you still need favicon.ico?

Only for very old browsers. Every current browser reads PNG favicons happily.

Some tools, feed readers and crawlers still request /favicon.ico from the site root without reading your HTML, so serving something there keeps your error logs quiet. It is not required for the icon to work.

Why your favicon will not update

Browsers cache favicons far more aggressively than other assets, sometimes for weeks, and frequently ignore a hard refresh entirely. This causes real confusion during redesigns, and people often conclude their file is wrong when it is fine.

The reliable fix is a version query on the href:

<link rel="icon" href="/icon-32.png?v=2">

Changing the query changes the URL as far as the cache is concerned, and the new icon appears immediately. Bump the number whenever the icon changes.

Use absolute paths

Reference everything with paths beginning with a slash.

Relative paths break on any page that is not at the site root, which typically produces the confusing symptom where the icon appears on your home page and vanishes everywhere else.

The manifest

The web manifest is a small JSON file telling Android and installable web apps what your site is called and which icons to use. Without it, adding your site to a phone home screen produces a screenshot of the page rather than an icon.

{
  "name": "Your Site Name",
  "short_name": "Your Site",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ],
  "theme_color": "#2563eb",
  "background_color": "#ffffff",
  "display": "standalone"
}

Two fields worth understanding. theme_color tints the browser toolbar on Android. background_color is painted behind the splash screen while the app loads, so it should match your page background rather than your brand colour if you want that transition to look seamless.

The test that matters

Build the icon, then look at it at 16 pixels next to five other tabs.

Not in a preview panel at 200 pixels. In an actual tab strip, at actual size, surrounded by competitors. If you cannot identify it in half a second, it does not work, however good it looks in the design file.