Favicon in 2026: The Exact Set of Files, Sizes and Formats

One square source, four outputs, and the whole legacy spread is covered. The 48×48 ICO (a modern multi-size ICO containing 16/32/48 is even better) handles the implicit /favicon.ico request and any old desktop chrome. The 32×32 PNG is the tab and bookmark icon, linked explicitly as a shortcut icon. The 180×180 apple-touch-icon — without transparency, on a solid background — is what iOS and iPadOS put on the home screen, and Android picks it up for shortcuts too when no maskable variant exists. The 512×512 PNG, declared in a web app manifest, serves PWA install prompts and the Android launcher with its adaptive-icon mask applied.

That is genuinely all a normal site needs. The size matrices you will find in older tutorials — every combination of 57, 60, 72, 76, 114, 120, 144, 152 — were real answers for versions of iOS that no longer ship; the platforms converged on 'ask for the manifest or pick one large source and mask it', which is why the set above is smaller than the folklore.

ICO is a Microsoft-era container: multiple raster sizes in one file, chosen by the consumer at request time. Its surviving relevance is behavioural — every browser still fetches /favicon.ico unprompted when no explicit link tag covers it, and a surprising number of older surfaces (bookmarks in desktop browsers, some OS file managers) never learned the modern routes.

The practical handling: serve a real 16/32/48 multi-size ICO at the site root so the implicit request hits something, declare PNG links in the HTML for the explicit consumers, and stop worrying. ICO generation is exactly what the favicon tool exists for — the hand-work of packing three bitmaps into the container is not a task worth doing twice.

The tab renders your design at 16×16 physical pixels — a budget your full logo has never fitted. The reliable compressions: single glyph, one or two flat colours, no strokes thinner than a pixel, no text. If the shape needs an outline to survive, it is not a favicon; if it reads at tab size squinted through half-closed eyes, it is one.

Two technical notes that save more time than design theory: transparency on a light tab strip versus a dark one flips which version of your mark is legible — the SVG (or a second declaration) with a CSS media query is now the clean answer in supporting browsers; and the browser's own downscale of a 512 source produces mush, so ship the 32 px raster as its own file rather than trusting the browser's resizer.

The declaration pattern: a rel="icon" link per size and type (or a modern single SVG plus PNG fallback pair), an explicit rel="apple-touch-icon" pointing at the 180 PNG, and a manifest.json listing the 192 and 512 PNGs with their purposes — any and maskable, since Android's adaptive icons crop to a circle/squircle and your mark needs the safe margin inside that mask.

The missing manifest is the most common cause of the 'favicon works, home-screen icon is a screenshot' complaint: without a manifest, installers fall back to whatever they can scrape, and the result is exactly as polished as you would expect.

Favicons are cached with unusual persistence — a separate cache from the rest of the site in some browsers, keyed to the URL, and refreshed on nobody's schedule you can control. When it will not update: hard-reload the page, then try the direct icon URL in a new tab (the real cache to bust), then a version query (?v=2) on the href as the honest developer escape hatch.

One scope note for site owners with traffic: the implicit /favicon.ico request fires on every navigation, so serving it from a CDN cache with a long max-age quietly removes one request-path hit per page view from your logs — the file is small but it is the most-requested asset almost no site optimises.