The sizes that matter
A practical set is small: 16 × 16 and 32 × 32 for browser tabs, 180 × 180 for an Apple touch icon, 192 × 192 and 512 × 512 for an Android home screen and a web app manifest. The generator on this site emits exactly that set, and the markup below is the same list it returns:
| File | Size | Declared as |
|---|---|---|
| /favicon-32x32.png | 32 × 32 | <link rel="icon" sizes="32x32"> |
| /favicon-16x16.png | 16 × 16 | <link rel="icon" sizes="16x16"> |
| /apple-touch-icon.png | 180 × 180 | <link rel="apple-touch-icon"> |
| /android-chrome-192x192.png | 192 × 192 | <link rel="icon" sizes="192x192"> |
| /android-chrome-512x512.png | 512 × 512 | <link rel="icon" sizes="512x512"> |
Measured from the icon-links helper the favicon page uses. The manifest should also list the 192 and
512 files with their own sizes and purpose.
Why .ico still exists
The ICO format is a container for several images, traditionally 16 × 16, 32 × 32 and 48 × 48, and
Windows and some older browsers still request /favicon.ico by convention even when the
page declares PNG icons. A multi-size ICO answers that request without a redirect and lets a legacy
client pick the size it needs. The PNG set remains the better choice for modern browsers because each
size can be optimised independently; the ICO is compatibility, not the primary format.
Keep the file at the site root as well as declaring it in the markup. A browser that has no declared
icon will fall back to /favicon.ico, and a missing file means a 404 on every page load —
the kind of noise that is easy to miss until you read a server log.
Markup, caching and stale icons
Declaring the icons in <head> is a list of links, not a single tag. Order does not
decide the winner; the sizes attribute lets the browser choose. A common mistake is to
declare a 512 image as rel="icon" with no sizes and then wonder why a tab looks blurry:
the browser scales it down, but it also has no smaller source to choose for a dense tab bar.
Icons are cached aggressively and browsers are inconsistent about when they re-check them. After replacing an icon, a hard refresh may not be enough; opening the icon URL directly, clearing the site data, or changing the filename are the reliable ways to force a refresh. Changing the filename is also what makes a cache-busting query string unnecessary.
SVG icons, manifests and theme colour
An SVG favicon scales cleanly and can adapt to a dark theme with a media query inside the file, but it
is not universally supported in every context — tab bars, bookmarks and older clients vary. Ship SVG
alongside PNG rather than instead of it, and keep the PNG set as the fallback. The web app manifest is
a separate surface: it lists the 192 and 512 icons plus the app name, start URL and theme colour, and
a home-screen install reads those, not the <link rel="icon"> tags.
Maskable icons are the other detail. Android may crop a home-screen icon to a circle or a squircle, so a maskable icon needs its important content inside a safe zone — roughly the central 80% — or the edges will be cut. A regular icon can fill the square; a maskable one needs padding. Declaring the same file as both without that padding is how a logo loses its edges on a phone.
Designing a small icon
A favicon is read at 16 pixels, which is smaller than most logos can survive. Use a single shape with a strong silhouette, avoid text, and check the result at 16 px rather than at 512. Transparent backgrounds are supported in PNG and ICO; a solid background is safer on dark and light tab bars because a transparent icon with dark strokes can disappear into a dark theme. For Apple touch icons, transparency is composited onto black by some versions of iOS, so provide an opaque square.
Placeholder images and data URLs are for development, not for the final tag. A placeholder at the exact dimensions lets you build the layout before the artwork exists; a data URL inlines a small icon and avoids a request, at the cost of making the HTML larger and the icon harder to cache separately. Move to real files before shipping.