The Legacy Favicon Tags You Can Finally Delete (And the Four You Can't)
Most favicon snippets on the web still carry a decade of dead tags: mask-icon, browserconfig.xml, msapplication-*, precomposed icons. Here's what each one did and which are still doing work.
Quick answer: a modern site needs four icon declarations — favicon.ico, a PNG icon, apple-touch-icon, and a web manifest. Almost everything else you'll find in copy-pasted snippets (rel="shortcut icon", mask-icon, browserconfig.xml, the msapplication-* meta tags, apple-touch-icon-precomposed, and a long ladder of PNG sizes) is there for browsers that no longer exist or no longer read it.
If you've ever pasted a favicon snippet and wondered why it was eighteen lines long, this is why. Generators have been accreting tags since roughly 2011 and removing almost nothing, because a dead tag is invisible — it costs a few bytes and never throws an error. The result is that most sites carry a small museum in their <head>.
Here's what each one actually did, and whether it's still doing anything.
The four that still matter
favicon.ico
<link rel="icon" href="/favicon.ico" sizes="32x32">
Still earning its place, for a reason that has nothing to do with browsers being old: every browser will request /favicon.ico from your site root whether you declare it or not, and plenty of non-browser clients — RSS readers, link-preview generators, chat unfurlers, some crawlers — only ever look for that exact path. A multi-resolution .ico containing 16, 32 and 48px is the universal fallback. It costs a few kilobytes and stops a guaranteed 404 in your access logs.
The sizes="32x32" hint is optional but useful: it tells browsers what's in the file without downloading and parsing it first.
A PNG icon
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
Modern browsers prefer PNG over ICO when both are offered, and a 32×32 PNG covers standard and high-density tab rendering well. You can add a 16×16 too, though the practical difference is small — browsers downscale competently these days.
An SVG icon is a good optional addition here, since one file stays crisp at any size and can carry a dark-mode media query. Add it alongside the ICO and PNG, never instead of them.
apple-touch-icon
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
The single most important non-.ico tag, because iOS ignores favicon.ico and the manifest icons entirely when someone adds your site to their home screen. Without this tag, iOS generates a screenshot of your page as the icon, which looks exactly as bad as it sounds.
180×180 PNG, no transparency (iOS fills transparent areas with black), and no pre-rounded corners — iOS applies its own rounding, and pre-rounding produces visible double corners.
The web manifest
<link rel="manifest" href="/site.webmanifest">
This is where Android, Chrome's install prompt, and PWA behaviour get their icons from — including maskable icons for adaptive home-screen shapes. It's also where theme_color, background_color and the app name live. Everything the old Microsoft and Chrome-specific meta tags used to do, the manifest now does properly.
That's the whole modern set. Four tags.
The ones you can delete
rel="shortcut icon"
<!-- delete -->
<link rel="shortcut icon" href="/favicon.ico">
shortcut was never a real link relation. It was an Internet Explorer invention that the rest of the web copied, and the HTML spec explicitly documents it as a non-conforming value kept alive only for compatibility. Browsers parse it as icon and ignore the shortcut part.
If you have both rel="shortcut icon" and rel="icon" pointing at the same file, you have one redundant tag. Delete the shortcut one.
mask-icon
<!-- almost certainly deletable -->
<link rel="mask-icon" href="/safari-pinned-tab.svg" color="#5bbad5">
This was Safari's pinned-tab icon on macOS: a flat, single-colour SVG silhouette that Safari tinted with the color value when you pinned a tab. It solved a real problem in 2015, when Safari didn't render normal favicons in pinned tabs at all.
Safari has since adopted standard favicons for its tab UI, and the tag has been on its way out for years. It does no harm if you keep it — it's inert in every other browser — but it's a maintenance liability: it's a separate piece of artwork, in a format nothing else uses, that has to be redrawn every time your logo changes, and it's the file people most often forget to update. If you delete anything from this list, delete this one.
browserconfig.xml and the msapplication-* meta tags
<!-- delete -->
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-TileImage" content="/mstile-144x144.png">
<meta name="msapplication-config" content="/browserconfig.xml">
These fed the Live Tiles on the Windows 8 and Windows Phone Start screens — the ones that flipped over to show updates. Live Tiles are gone, Windows Phone is gone, and Internet Explorer is gone. Nothing reads these tags now.
The browserconfig.xml file that goes with them can go too, along with the mstile-*.png files a generator produced for it. That's typically five or six files removed from your project root for zero functional change.
apple-touch-icon-precomposed
<!-- delete -->
<link rel="apple-touch-icon-precomposed" href="/apple-touch-icon-precomposed.png">
Before iOS 7, the system added its own gloss-and-bevel effect to home-screen icons, and precomposed was how you opted out and said "my artwork is already finished." iOS 7 dropped skeuomorphic icon effects entirely in 2013, which made the distinction meaningless. Modern iOS treats both the same.
The size ladder
<!-- mostly deletable -->
<link rel="apple-touch-icon" sizes="57x57" href="/apple-touch-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="/apple-touch-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="/apple-touch-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/apple-touch-icon-76x76.png">
<!-- ...and six more -->
This ladder exists because early iOS versions picked the exact-match size and did a poor job scaling when they had to. Current iOS downscales a single 180×180 icon cleanly for every surface it needs.
Ten <link> tags and ten files, replaced by one. Some very old devices will get a downscaled icon instead of a purpose-made one; if your analytics show meaningful traffic from iPhones old enough to care, keep the ladder. Otherwise it's ten files nobody will ever update in sync.
<meta name="application-name"> for icon purposes
Harmless, and it can be legitimately useful as a name hint, but it doesn't affect icons at all. If you have a manifest with a name and short_name, it's duplicated information.
What a cleaned-up <head> looks like
<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/svg+xml" href="/icon.svg">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">
<meta name="theme-color" content="#ffffff">
Six lines, covering browser tabs, retina tabs, scalable and theme-aware rendering, iOS home screens, Android and PWA installs, and the mobile browser UI colour. Compare that to the eighteen-line block most generators still hand out.
Before you delete anything
Two cautions, because "it's legacy" is not the same as "nothing reads it":
Check what's actually declared first. Sites accumulate icon tags from several sources — a theme, a plugin, a framework module, and whatever a previous developer pasted in. Deleting the line you can see doesn't help if a plugin is injecting another one below it. Run your live URL through the Checker and it will list every icon declaration in the served HTML, so you're editing against reality rather than against your template.
Delete the tag and the file together. A leftover safari-pinned-tab.svg or mstile-150x150.png sitting in your public directory is confusing rather than harmful, but it's exactly the kind of thing that gets re-added to a snippet six months later because someone found the file and assumed it was needed.
Then regenerate the set properly. The Generator exports the modern six-line set and the files that go with it — nothing you'll have to come back and delete in 2032.
◎ Try the Checker
Point it at a URL and get a graded report of every icon a site declares — plus how each one looks on real devices.
Open CheckerWritten by Abdessamad Bettal
Web developer, and the person who builds and writes favicon.tools. The ICO packer, manifest writer and site checker behind favicon.tools were all written from the file-format specs and tested against real browsers — which is where the detail in these guides comes from. Spotted something wrong? Write to contact@favicon.tools.