Favicon sizes in 2026: what you actually need

Search for favicon sizes and you will find tutorials asking for eleven files, a dozen <link> tags and a browserconfig.xml. Those tutorials are largely copies of each other, and most of what they ask for is there to satisfy browsers and platforms that no longer exist.

The list has got shorter, and the reasoning behind the short list is more useful than the list itself, because it tells you what to do when something new turns up.

Support figures as of 18 August 2026. Check against current documentation before you delete anything from an existing site.

Why there were ever eleven

Three historical pressures, all now largely gone.

Internet Explorer fetched /favicon.ico from the site root unless a <link> pointed it elsewhere, and wanted a real .ico to do it. Windows tiles wanted their own sizes declared in their own XML file.

iOS wanted an apple-touch-icon at a different pixel size for each device generation, and authors shipped one per device rather than let it resample. So you shipped seven.

Android had its own add-to-home-screen conventions before the web app manifest settled it.

All three have converged. Modern iOS scales a single large touch icon. Android reads the manifest. The tile format is gone. What remains is a much shorter list.

The six files

favicon.ico — still at the site root, still worth having. Not for old browsers but because several things look for it by convention without being told to, and because it can contain multiple sizes in one file. Put 16, 32 and 48 inside it.

favicon-32x32.png — the size browsers reach for on high-DPI displays and in bookmark and history lists, and the one worth getting visually right.

favicon-16x16.png — the small case: crowded tab bars, bookmark lists, some address bars.

apple-touch-icon.png at 180 × 180 — iOS home screen. One file: where no icon matches the device’s preferred size, iOS takes the smallest one larger than it and scales that. Safari has read manifest icons since 15.4, but an apple-touch-icon still takes precedence over them.

icon-192.png — Android home screen and the installable-app case, referenced from the manifest.

icon-512.png — splash screens and app listings, also from the manifest. If you want the Android adaptive-icon treatment as well, add a second 512 file drawn for the safe zone and declare that one with purpose: "maskable" — not the same file twice, for the reason two sections down.

Six files, seven with a maskable variant. Five <link> tags and a manifest. That is the whole thing.

The .ico format, briefly

An .ico is not an image format, it is a container: a six-byte header, a directory of entries, and then the image data. Each entry can hold a BMP or, since Windows Vista, a complete PNG file byte for byte.

Current browsers read the PNG form, which is why a modern favicon generator packs PNGs and skips the BMP encoder, the palette and the AND-mask arithmetic entirely.

One quirk worth knowing if you ever look at the bytes: the width and height fields are a single byte each, so 256 does not fit. The format’s answer is to write 0 and mean 256.

Maskable icons, and why yours looks wrong on Android

This is the modern mistake, and it is the one that makes an otherwise careful icon look broken.

Android applies a mask to home-screen icons — a circle, a rounded square, a squircle, depending on the launcher and the manufacturer. For an icon you declared maskable it does not fit your icon inside the shape; it crops your icon to the shape. Anything in the corners is cut off, and an icon designed to fill its square loses its edges. An icon you have not declared maskable is not cropped — Chrome gives it a white background instead, which is its own kind of wrong.

The maskable purpose in the manifest tells Android the icon is designed for this. A maskable icon needs its meaningful content inside a safe zone: a circle covering the middle 80% of the image, centred. Everything outside that circle is decoration that may be cropped, and should be background colour rather than part of the mark.

The practical consequence is that a maskable icon usually needs its own artwork — the same mark, smaller, on a filled background — rather than the same file reused. Declaring an ordinary icon as maskable gives you a cropped logo on most Android phones.

Designing something legible at 16 pixels

A favicon is 16 pixels on a standard display. That is smaller than a word.

Which means: it is not your logo. A wordmark is illegible, a detailed illustration turns to mush, and a thin-stroked line drawing disappears into the tab background.

What works is a single strong shape with high contrast — one letter, one symbol, one silhouette, filled rather than outlined, with generous internal spacing. Test it by shrinking it to 16 pixels and looking at it beside your other tabs, in both light and dark browser themes. A dark mark on transparency vanishes on a dark tab bar; a light mark vanishes on a light one. If your mark is monochrome, give it a background.

Start from something square and centred — crop it first rather than letting a generator letterbox a wide logo into a square and produce something tiny with white bars.

SVG favicons

Browsers increasingly accept an SVG favicon, which is appealing: one file, sharp at every size, and in Chromium and Firefox it can respond to the user’s colour scheme with a prefers-color-scheme media query inside the SVG itself.

Two caveats keep it from replacing the list. Every current engine reads one now — Firefox since 41, Chrome since 80, Safari only since 26.0 in September 2025 — so you still ship the PNG and ICO fallbacks, for older Safari and for everything that is not a browser; the SVG saves you nothing in file count. And SVG rendering at 16 pixels is unforgiving: thin strokes and small detail alias badly, because there is no hinting. An SVG favicon usually needs a simplified variant for small sizes, at which point you are back to designing for the size rather than scaling.

Worth adding as an enhancement. Not worth deleting the fallbacks for.

The markup

<link rel="icon" href="/favicon.ico" sizes="16x16 32x32 48x48" type="image/vnd.microsoft.icon">
<link rel="icon" href="/favicon-32x32.png" type="image/png" sizes="32x32">
<link rel="icon" href="/favicon-16x16.png" type="image/png" sizes="16x16">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">

The manifest carries the 192 and 512 icons, the maskable declaration, the theme colour and the display mode. Everything Android and the installable-app case needs lives there rather than in <head>.

If you have inherited the eleven-file pack

You probably should not rip it out on a Friday afternoon. Extra files cost you a few kilobytes that are requested once and cached forever; a missing file costs you a broken icon on a device you cannot test. The asymmetry argues for patience.

A reasonable order, safest first. Delete the browserconfig.xml and the msapplication-* meta tags — the tile format they serve is gone. Delete the stack of per-device apple-touch-icon-76x76, -120x120, -152x152 and friends, keeping only the 180. Delete favicon-96x96 and any of the other odd intermediate sizes; nothing asks for them. Keep the .ico, the 16, the 32, the 180 and the two manifest icons.

Then check the manifest, because the file that most often turns out to be wrong on an older site is the one nobody looks at: icons pointing at paths that moved, no maskable declaration, or no manifest link in <head> at all.

And check the actual bytes before you trust an inherited set. A surprising number of sites ship a favicon-32x32.png that is a 16-pixel image scaled up, because a generator was fed a small source once and nobody looked since.

Two things that waste an afternoon

Caching. Browsers cache favicons aggressively and out of band from normal page caching. Your new icon will not appear, and you will change it again, and it still will not appear. Test in a private window, or append a query string, before concluding anything is wrong with the file.

Root paths. favicon.ico is looked for at the site root by things that never read your HTML. Put it there even though the <link> tag names it explicitly.

Generating the set

The whole job is one square source image, six or seven outputs, a manifest and five tags — which is why it should take a minute rather than an afternoon, and why it does not need an upload. The generator does the resizing and the ICO packing in the browser and hands back a zip with the markup included, so the source image never leaves the machine it was designed on.

If your source is not square, or is a wide wordmark, fix that first. Everything downstream is arithmetic; the composition is the only decision.