Blog
Why One Favicon Isn't Enough Anymore
The history of the favicon format and the multi-size, multi-format reality modern browsers and operating systems actually expect.
In 1999, Internet Explorer 5 introduced a small feature: if a site placed a file calledfavicon.ico at the root of its domain, the browser would show it next to the URL and in the bookmarks list. That was the entire spec. One file, one size — 16x16 pixels — one format. Twenty-five years and a dozen device categories later, a "favicon" for a modern site can reasonably mean eight or nine separate image files, and shipping just the original 16x16 ICO will leave the site looking broken or generic on a surprising number of devices.
Where the single-file era broke down
The ICO format itself is unusual: it's technically a container that can bundle multiple image sizes into one file, which is why old favicons often included 16x16, 32x32, and 48x48 versions stacked inside a single .ico. That worked fine as long as "favicon" only meant "the little icon in the browser tab." But browsers started using it for more — pinned tabs, bookmark bar entries, browser history thumbnails — each wanting a slightly different size for crisp rendering. Then came mobile. iOS and Android don't render a page inside a tab bar at all when a user adds a site to their home screen; they need a large, dedicated icon image, and ICO was never the format either platform standardized on.
What each platform actually asks for
Apple's iOS and iPadOS look for a link tag pointing to an apple-touch-icon, conventionally a 180x180 PNG, used whenever someone adds the site to their home screen — no ICO fallback, no negotiation. Android's Chrome, when a site provides a web app manifest, will pull icon sizes declared there, commonly 192x192 and 512x512, for its home-screen and splash-screen treatments. Windows tiles (a largely legacy feature now) historically wanted their ownbrowserconfig.xml-declared sizes. Modern desktop browsers increasingly accept a plain favicon.svg for the tab icon, since a vector scales cleanly across the various small resolutions a tab icon might render at, with a PNG fallback for browsers that haven't added SVG favicon support. The result is that "make a favicon" quietly turned into "produce a small set of correctly-sized image assets across at least three formats," which is a lot to expect someone to do by hand in an image editor.
Why you can't just scale one image down
It's tempting to think a single high-resolution source image solves this — just downscale it to whatever size each platform wants. That's roughly right for the resizing math, but detail is the catch: a logo with fine text or thin linework that reads perfectly at 512x512 can turn into an illegible smudge at 16x16, because there simply aren't enough pixels left to represent the detail. This is the same resampling limit that applies to any image being scaled down aggressively, but it matters more here because a 16x16 tab icon has almost no margin for error — a few blurry pixels either read as the intended shape or they don't. Good favicon generation usually means simplifying the source mark for the smallest sizes (thicker strokes, less detail, sometimes a completely different simplified glyph) rather than mechanically resizing one image down to every required dimension.
The manifest and link tags nobody sees
None of these image files do anything on their own — each one has to be referenced from either the page's <head> via <link rel="icon"> and<link rel="apple-touch-icon"> tags, or from a site.webmanifestJSON file that the page links to. Miss the manifest entry for the 512x512 icon and Android will silently fall back to a generic placeholder when a user saves the site to their home screen, with no error or warning anywhere — it just looks unfinished. This is the part of favicon setup that trips people up even after they've correctly generated every image size: producing the right files is only half the job, and wiring up the corresponding markup is the other half. Afavicon generator that outputs both the image set and the matching HTML/manifest snippets saves the tedious part of tracking down which platform expects which tag, in which size, in which format.