Ask a favicon generator for a set and you will get thirty files and twenty lines of markup, most of it addressing browsers and devices that stopped mattering years ago.
The genuinely useful set is much smaller. Here is what each file is actually for, and what you can drop.
The set that earns its place
favicon.ico, at the site root. Containing 16×16 and 32×32. Browsers still request /favicon.ico directly without being told to, so this file gets fetched whether you reference it or not — and if it is missing you take a 404 on every fresh visit. It is the one file whose location is not negotiable.
A 32×32 PNG. The browser tab, at standard density.
A 180×180 PNG — the Apple touch icon. Used when someone adds your site to an iOS home screen. iOS will not use your other icons for this, and without it you get a screenshot of the page, which looks like neglect.
A 192×192 and a 512×512 PNG. The Android and progressive-web-app sizes, referenced from the manifest rather than the markup.
A maskable icon. Distinct from the above, and the one most sets get wrong — see below.
site.webmanifest. A small JSON file naming your site, its theme colour and its icons. Required for a site to be installable, and cheap regardless.
That is the working set: one ICO, four or five PNGs, one manifest. Our favicon generator produces exactly this from a single source image, plus the markup snippet, as a ZIP.
What you can drop
The whole Microsoft tile family — browserconfig.xml and the msapplication-* meta tags. These served Windows 8 Start-screen tiles. That interface is gone.
Most intermediate PNG sizes. Sets offering 24, 48, 57, 60, 70, 72, 76, 96, 114, 120, 144, 150 and 384 are addressing long-superseded device generations. Browsers downscale competently from a larger source.
Per-device Apple touch icons. Modern iOS scales one 180×180 correctly. The era of a separate file per handset is over.
The Safari pinned-tab SVG. A monochrome silhouette for a Safari feature that no longer requires it. Harmless, rarely necessary.
If your current set has thirty files, roughly twenty-four are doing nothing.
The maskable icon, which nearly everyone gets wrong
This is the one worth understanding properly.
When Android installs a web app, it applies a mask to the icon — a circle, a squircle, a rounded square, depending on the launcher. The mask is decided by the device, not by you.
A normal icon fills its canvas. Mask that to a circle and the corners are cut off. A logo with text near the edge loses the text; a square mark becomes a circle with its corners shaved.
A maskable icon solves this by including deliberate padding. Everything important sits inside a safe zone — a circle covering roughly the central 80% — and the outer margin is background colour that any mask can safely remove.
Two consequences people miss:
The maskable icon is a different file. Not a flag, not a manifest property applied to your existing icon. It is a separately prepared image with the padding built in, declared in the manifest with "purpose": "maskable". Supplying your normal icon with that purpose set produces a cropped mess.
Your logo appears smaller. That is correct, not a mistake to compensate for. Padding it back out defeats the purpose.
Our generator enforces a minimum of 20% padding when producing the maskable variant, because the commonest failure is a source image that already fills its frame being passed through unchanged.
What makes a good source image
Start from a vector if you have one. Rasterise from the SVG at each size rather than scaling a PNG down — every size rendered from the source stays sharp.
Design for 32 pixels, not for 512. The tab icon is the one people see constantly, and it is tiny. Detailed marks turn to mush. Wordmarks are unreadable. A single letter, a simple glyph or a bold silhouette is what survives.
Use a solid background for the maskable version. Transparency plus a mask produces unpredictable results across launchers.
Test against both light and dark browser chrome. A dark icon on a transparent background disappears in a dark-themed tab strip. If your mark is monochrome, give it a background.
The markup
Four lines is enough:
<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/icon.png" type="image/png">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">The 192, 512 and maskable icons are declared in the manifest rather than here.
Two practical notes. Favicons are cached aggressively — often beyond a normal hard refresh — so test changes in a private window or with the cache disabled, and expect the old one to persist for some visitors regardless. And put the ICO at the site root even if everything else lives in a subdirectory, because that is where browsers look unprompted.
The SVG favicon, and why it is optional
Modern browsers accept an SVG favicon, declared like any other icon. It is genuinely appealing — one file, sharp at every density, and it can respond to the browser’s colour scheme with a media query inside the SVG itself, so a dark-mode tab gets a light icon automatically.
The reasons it is a nice-to-have rather than a replacement: the ICO is still fetched from the root regardless, older browsers ignore the SVG entirely, and neither iOS home screens nor Android launchers use it. It is an addition to the set, not a substitute for it.
If your mark is simple enough to work at 32 pixels, it is simple enough to be a small SVG, and adding one costs a line of markup.
Theme colour, while you are there
The manifest carries a theme_color, and there is a matching meta tag. Between them they set the colour of the browser chrome on mobile and the splash background when an installed app launches.
It is two lines and it is the difference between an installed app that looks considered and one that flashes white before it loads. Set it to match your icon’s background rather than to your brand’s primary colour, unless those happen to be the same — the visual join people notice is between the splash screen and the icon, not between the splash screen and your website.
Testing, and the caching problem
Favicons are cached more aggressively than almost anything else a browser stores, frequently surviving a hard refresh and sometimes a browser restart.
This produces a specific and very common waste of time: you change the icon, reload, see the old one, and conclude the change did not work. Then you change something else, and now two things are uncertain.
The reliable checks:
- Test in a private window, which starts with no icon cache.
- Request the file directly — open
/favicon.icoor/icon.pngas a URL and confirm the server is serving what you uploaded. This separates “did it deploy” from “is it cached”, which are the two questions that get conflated. - Check the manifest parses. Browser developer tools show the parsed manifest and will flag a malformed one. A single trailing comma silently disables installability.
- Expect existing visitors to keep the old icon for a while regardless. There is no way to force a refresh, and changing the filename is the only reliable cache-bust.
Turn one image into the full icon set, manifest and markup snippet, in your browser, with our favicon generator. Nothing is uploaded.