Favicons: What Sizes You Actually Need in 2026
Published 5/21/2025 · 13 min read · Image & design tools
Daniel Okonkwo — Front-end developer and tech writer at OneKitly
Web performance · File formats
Checked against 6 sources
Five files. A favicon.ico at the site root, drawn at 32×32, because browsers and feed readers still request that exact path with no markup at all. An icon.svg for the tab, which scales to any size a browser asks for and is now read by Chrome and Edge since version 80, Firefox since 41, and Safari since version 26 — about 89% of global traffic. A 180×180 apple-touch-icon.png with an opaque background, for the iOS home screen. A 192×192 and a 512×512 PNG declared in the web app manifest, which is what Chrome requires before it will offer to install the site, plus a maskable variant if you want Android launchers to reshape it cleanly. That is the whole list, and on our test mark it totals 57,391 bytes, against 272,192 bytes for the twenty-six-size matrix a legacy generator produces. An ordinary page view fetches only two of those files, 1,918 bytes. The one thing the file list will not fix: a 16-pixel icon has 256 pixels, one thousand and twenty-fourth of a 512-pixel canvas, and a scaled-down logo loses fine detail entirely. On our mark the bold letter kept 94% of its contrast at 16 pixels; the small tagline kept 15%.
Five files cover every consumer that exists: the tab, the bookmark, the pinned tile, the Android home screen and the iOS home screen. The twenty-file lists are a dead browser matrix — with measurements showing what a 16-pixel icon can and cannot hold.
Start from the consumers, not from the file list
There are exactly five places an icon for your site ends up, and each of them reads one specific thing. The browser tab and the bookmark bar read whatever the head declares as rel="icon", preferring a vector if you offer one. Anything that guesses — old browsers, feed readers, link previewers, a surprising amount of internal tooling — requests /favicon.ico at the site root with no markup involved at all. The iOS and iPadOS home screen reads apple-touch-icon.png. The Android home screen and the Chrome install prompt read the icons array in the web app manifest. That is the complete list of consumers, and it has not grown in years.
Read that list again and notice what is missing. There is no consumer that wants 57 pixels, or 70, or 114, or 144, or 310. Those numbers come from a specific historical matrix: Internet Explorer's pinned-site tiles, a decade of iOS devices before the operating system learned to downscale one file, and a generation of Android launchers that predates the manifest. All three of those consumers are gone. What remains of them is generator output — twenty-something PNGs and a browserconfig.xml — sitting in the root of sites whose owners have no idea which of those files anything still reads.
The minimum set, and what the maximum set costs
We built both, from one 512×512 mark, and weighed them. The minimum set is favicon.ico at 1,664 bytes, icon.svg at 254 bytes, apple-touch-icon.png at 180×180 and 13,573 bytes, icon-192.png at 14,510 bytes and icon-512.png at 27,390 bytes: five files, 57,391 bytes. The legacy matrix — the same mark exported at 16, 24, 32, 36, 48, 57, 60, 70, 72, 76, 96, 114, 120, 128, 144, 150, 152, 167, 180, 192, 196, 228, 256, 310, 384 and 512 — is 26 files and 272,192 bytes, before the ICO and the two configuration files. That is 4.7 times the bytes and five times the files for exactly zero additional coverage.
The byte total is the least interesting part, because a visitor never downloads all of it. On an ordinary page view a browser fetches the tab icon and nothing else: our ICO plus our SVG is 1,918 bytes, and a browser that takes the SVG fetches 254. The apple-touch-icon and the manifest icons are only requested when somebody actually installs or bookmarks to a home screen. What the file count really costs is maintenance — 26 raster files that all have to be regenerated, consistently, every time the mark changes, and that nobody will ever check.
SVG in the tab: nearly everywhere now, still not everywhere
A vector tab icon is the single best change you can make, because it removes the entire question of which raster sizes to ship: the browser asks for whatever it needs and the renderer produces it. Chrome and Edge have read rel="icon" SVGs since version 80, Firefox since 41. Safari was the long holdout — it supported only its own monochrome pinned-tab format for years — and Safari 26 is the first version to render an ordinary SVG favicon in tabs and bookmarks. Support tables put the combined figure at roughly 89% of global traffic, and it is climbing as Safari installations update.
That last 11% is why the ICO stays. It is not there for the tab; it is there because /favicon.ico is a path that gets requested with no markup at all, by browsers too old for SVG and by every non-browser tool that wants a site icon and does not parse HTML. One 32×32 entry is enough. Keep it at the root, not in an assets folder, because the clients that ask for it by convention will not read your link element to find out where you moved it.
What sizes="any" does, and why that advice has changed
In the HTML standard the sizes attribute is a hint: a space-separated list of width-by-height values telling the browser what the resource contains, and the single keyword any, which declares that the resource is scalable — a vector. The browser is free to use it or ignore it. It is not a rendering instruction, and setting sizes on an image does not resize anything.
The advice you will find everywhere — put sizes="any" on the ICO — was never about that definition. It was a workaround for a Chrome behaviour: presented with an ICO and an SVG, Chrome downloaded both and used the ICO, so people declared the ICO as "any" to push Chrome toward the SVG. That worked, but it says something untrue about the file. The current recommendation from the same people who popularised the trick is to declare the ICO honestly as sizes="32x32" instead — it resolves the same double-download and it does not lie about what is in the file. If you copied a favicon snippet before about 2023, this is the line worth updating.
A 16-pixel icon is not a scaled-down 512-pixel icon
This is the part the file list cannot help with. A 512×512 canvas holds 262,144 pixels. A 16×16 canvas holds 256 — one thousand and twenty-fourth as many. Every feature in your mark has to survive being averaged down into that budget, and averaging is exactly what antialiasing does: a stroke thinner than one output pixel does not become a thin line, it becomes a faint tint spread across the pixels it partly covers.
We measured it on one mark: a bold letter, a wordmark set at 52 pixels, a tagline set at 24, and an 8-pixel white ring, all on a 512 canvas. The mark holds 407 distinct colours at 512 and 85 at 16. Measuring the luminance contrast each feature still has — the difference between its lightest and darkest pixel — the bold letter goes from 199.4 levels at 512 to 188.0 at 16: it survives, at 94% of its contrast. The wordmark goes from 199.4 to 86.4 — 57% gone. The tagline goes from 199.4 to 29.1 — 85% gone. At that point it is not small text, it is a grey bar.
The ring is the clearest single case, because we can follow one scanline through it. On the 512 master the ring's stroke reads as pure white, luminance 255 against a background of 56 — a contrast of 199. At 192 it is still 255. At 48, where the 8-pixel stroke is down to 0.75 of an output pixel, its brightest point reaches only 159. At 32 it reaches 121. At 16, where the stroke is a quarter of a pixel wide, the brightest point on the whole ring is 99 against a background of 52: a contrast of 47, down from 199. Three quarters of the ring's presence is gone, and no amount of sharpening in the export dialog puts it back — the information is below the sampling grid.
The practical consequence is a design rule, not a file rule: at 16 pixels a mark can hold one bold shape and nothing else. If your logo is a wordmark, the favicon is its first letter or its symbol, not the wordmark. If it has a hairline, thicken it or drop it. Draw a separate simplified version for the small sizes if you care about the tab — and if you do, that is the one case where hand-drawing a 16-pixel and a 32-pixel raster beats letting a downscaler decide.
The two files that are not favicons at all
The apple-touch-icon and the manifest icons get lumped into favicon checklists, but they are app icons, and they behave like app icons. The apple-touch-icon is 180×180, which is the 60-point iOS icon at 3× density, and iOS scales that one file down for every other device — the old ladder of 57, 72, 76, 114, 120, 144 and 152 is unnecessary. Two things matter about it: iOS applies its own rounded-rectangle mask, so a mark that runs to the edge gets its corners cut off; and iOS does not preserve transparency here, so a transparent background is flattened for you, and not necessarily to the colour you would have picked.
The manifest icons are what Chrome checks before it will offer to install a site: it wants a 192-pixel and a 512-pixel entry, and without both of them the install prompt simply never appears, with no error anywhere. Add a third 512×512 entry with purpose set to maskable if you want Android launchers to reshape the icon into a circle or a squircle without clipping your artwork — the safe zone for that is a central circle 409 pixels across on the 512 canvas, so about 80% of the width, and anything outside it may be masked away.
| Consumer | The file it reads | Size to export | Measured bytes |
|---|---|---|---|
| Browser tab and bookmark bar | icon.svg | Vector, any size | 254 |
| Older browsers, feed readers, anything that guesses the path | favicon.ico at the root | 32×32, one entry | 1,664 |
| iOS and iPadOS home screen | apple-touch-icon.png | 180×180, opaque | 13,573 |
| Android home screen and the Chrome install prompt | icon-192.png, via the manifest | 192×192 | 14,510 |
| Splash screens, launcher masks, app listings | icon-512.png, via the manifest | 512×512, plus a maskable twin | 27,390 |
| Total for the whole set | Five files | Against 26 files in a legacy matrix | 57,391 against 272,192 |
Frequently asked questions
- Do I still need a favicon.ico if I ship an SVG?
- Yes, and it costs almost nothing — 1,664 bytes for a single 32×32 entry in our test. Its job is not the tab. Its job is the requests that arrive with no markup: browsers older than Chrome 80 or Safari 26, feed readers, link previewers and internal tools that fetch /favicon.ico by convention. Put it at the site root, because those clients will not read your link element to find it elsewhere.
- Should my ICO contain 16, 32 and 48 pixel versions?
- Not usefully. We built both: a single 32×32 entry came to 1,664 bytes, and packing 16, 32 and 48 into one file came to 5,188 — more than three times the size. The clients still reading the ICO at all are the ones least likely to be picky about which entry they get, and modern downscaling from 32 to 16 is good. Spend the effort on the design at 16 pixels instead, which is what actually shows.
- Can one SVG favicon change colour in dark mode?
- It can, and this is one of the real advantages of the vector file. An SVG favicon may contain a style block, and a prefers-color-scheme media query inside it will be honoured by browsers that render the SVG, so a dark-mode tab can get a lighter mark without a second file. Do not build anything essential on it, though: the ICO fallback cannot do this, and neither can the apple-touch-icon or the manifest icons.
- Why does Chrome never offer to install my site?
- The most common cause is a manifest without both a 192-pixel and a 512-pixel icon. Chrome checks for those two sizes as part of its installability criteria, and when one is missing it does not warn you — the install button simply never appears. Check the application panel in the developer tools, which lists the manifest as parsed and says which requirement failed.
- Can I just export the 512 file at every smaller size and be done?
- You can, and for the 180, 192 and 512 pixel files that is exactly right — they are large enough to hold everything. It is the 16 and 32 pixel end where automatic downscaling stops being enough. On our test mark the small tagline lost 85% of its contrast at 16 pixels and the hairline ring lost 76%, so the icon that reaches the tab is a blur of the shapes you intended. Either simplify the artwork for those sizes or accept that the tab shows one bold shape.
Articles you may find interesting
All guides →Related tools
Sources
- WHATWG — HTML Standard — link type "icon" and the sizes attribute
- MDN Web Docs — The <link> element — rel="icon", sizes, and apple-touch-icon
- W3C — Web Application Manifest — the icons member and the maskable purpose
- web.dev — What does it take to be installable? — manifest icon requirements
- Can I Use — SVG favicons — browser support table
- Evil Martians — How to Favicon: six files that fit most needs
Spotted a mistake in this article?