Favicons: the five files you actually need

For a decade the standard favicon advice was a folder of thirty PNGs and a page of markup, because every platform had invented its own sizes and nobody dared delete any. The platforms have since consolidated; much of the advice has not. What browsers actually read in 2026 is five files and four lines in the head — and one of the five can do things the other four cannot.

1. How we got a folder of thirty icons

Apple once wanted a separate touch icon for every screen density it shipped — 57, 72, 76, 114, 120, 144, 152, 167 and 180 pixels each had their year. Windows 8 tiles asked for four more PNGs and a browserconfig.xml. Generators of the era faithfully produced all of it, and those folders still get copied forward from project to project. All of it is obsolete: iOS takes one 180 px icon and scales it, Windows tiles are gone, and the sizes in between were never load-bearing. Deleting the extra files loses nothing except requests.

2. The five files

The modern set: favicon.ico carrying 16, 32 and 48 px renders for legacy consumers and address-bar fallbacks; favicon.svg for every current browser that takes it; apple-touch-icon.png at 180 px for iOS home screens; and 192 and 512 px PNGs referenced from a site.webmanifest for Android and PWA installs. Wired up:

<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">

Two details are doing quiet work. The ICO is declared 32x32 rather than any so Chromium keeps preferring the SVG beside it. And the ICO belongs at the root as /favicon.ico regardless of what the tag says — crawlers, feed readers and old tooling request that path blindly and skip the markup entirely. The favicon generator produces the whole set from one SVG, including this snippet.

3. The SVG one is the interesting one

The SVG favicon is not just the scalable copy — it is a live document, and it can carry a stylesheet. That makes it the only icon in the set that can answer the operating system's dark mode:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32">
  <style>
    path { fill: #18212e; }
    @media (prefers-color-scheme: dark) { path { fill: #f6f8fa; } }
  </style>
  <path d="…" />
</svg>

The stylesheet lives inside the file for the same reason your page CSS cannot recolour it: a favicon is loaded as its own document, and nothing crosses that boundary in either direction — the rules are the ones from how embedding decides what CSS can do. Keep the fallbacks in place regardless: Safari still ignores SVG favicons and takes the ICO, which is also what pre-2020 browsers do.

4. Design for sixteen pixels

A favicon's most common rendering is a 16 px square in a crowded tab strip. At that size a wordmark is noise, thin strokes vanish between pixels, and detail reads as dirt. The mark that survives is one shape, high contrast, filling the frame — think glyph, not logo. If your logo does not reduce, crop it to its most recognisable element in the editor rather than shrinking all of it, and judge the result at actual size: the generator previews 16 px specifically because that is the test that fails.

5. The details that bite

• iOS fills transparency with black. The apple-touch icon must be composited onto a real background colour — brand colour or white, chosen, not defaulted.
• Android crops the manifest icons. Launchers mask icons into circles and squircles, keeping roughly the central 80%. Keep the mark inside that zone with padding, or corners get eaten.
• Favicon caches outlive everything. Browsers routinely ignore a reload where favicons are concerned. Ship a change as /favicon.ico?v=2 or verify in a private window before concluding it is broken.
• The manifest 404s quietly. A missing or misnamed site.webmanifest costs you the Android install icon and shows up only in devtools. After wiring the set, load each of the five URLs once by hand — thirty seconds that catches every typo.