Ship three files: an SVG, a 32×32 favicon.ico, and a 180×180 apple-touch-icon.png. That covers browser tabs, bookmarks, Google's search results, iOS home screens, and Android. If you also want a proper PWA install icon, add a 512×512 PNG in your web app manifest and you're genuinely done.
That's the answer. The rest of this post is about why you've read four different answers everywhere else, and which one applies to you.
Because here's the thing that makes favicons weirdly annoying for such a small file: search "favicon size" and MDN tells you 16×16, a well-regarded engineering blog tells you 32×32, Google's documentation tells you bigger than 48×48, and the top Reddit answer swears by 144×144. None of them are wrong. They're answering different questions, and almost nobody says which question they're answering.
If you just want to know whether your own setup is right, the favicon checker reads a live page and reports what actually resolves. If you want the wider picture of which head tags earn their place, start with the complete guide to meta tags for SEO. This one zooms into the icon.
Why the guides disagree
Four numbers, four different surfaces.
16×16 is the historical browser-tab size. It's what a favicon was in 1999 and it's still what MDN's glossary leads with. On a modern display it's not the rendered size any more, because a 2× screen wants 32 device pixels to fill a 16-point tab.
32×32 is what actually renders in a browser tab on the machine you're reading this on. It's also the number the Evil Martians favicon guide settled on after testing across platforms, and it's the single most useful raster size if you only ship one.
48×48 and up is Google's territory. That's the icon next to your result in search, and it's a completely different rendering context from a browser tab.
144×144 and friends come from the PWA and Android world, where the icon can end up on a home screen at whatever density the device fancies.
So the correct question isn't "what size is a favicon." It's "which surfaces do I care about." Almost everyone cares about all four, which is why three files beats one.
What Google actually requires (and one rule it never wrote)
This is worth getting exactly right, because there's a rule circulating that Google's own documentation doesn't contain.
Google's favicon documentation states a minimum of 8×8 pixels, and recommends "using a favicon that's larger than 48x48px so that it looks good on various surfaces" (Google Search Central, retrieved 2026-09-06). Supported formats are BMP, GIF, ICO, PNG, JPEG, PPM and TIFF. Supported rel values are icon, the historical shortcut icon, apple-touch-icon, and apple-touch-icon-precomposed.
Now the myth. You'll find pages ranking on page one of this exact query stating that favicons "must be a multiple of 48px": 48×48, 96×96, 144×144. Google's documentation doesn't say that. It says larger than 48×48. A 64×64 icon isn't disqualified for failing to be a multiple of anything.
Where the confusion probably comes from: multiples of 48 are sensible for the same reason multiples of 8 are sensible in a design system. They downscale to 48 cleanly. That's a good habit dressed up as a requirement. Repeated often enough, it starts to read like spec.
The practical version: make it square, make it bigger than 48, don't sweat the exact multiple.
What shows up if you get it wrong
Nothing dramatic. That's part of why favicons stay broken for months.
If Google can't find or can't use your icon, it falls back to a generic globe next to your result. Your page still ranks exactly where it ranked. You just look slightly less like a real site than the nine results around you, on a SERP where every other favicon is doing quiet brand work.
Same story in the browser. A missing icon gets you the blank-page glyph, which is invisible until someone has fifteen tabs open and is scanning for yours. Then it's the only tab they can't find.
Neither of these throws an error, appears in a report, or shows up in Search Console. It's a purely visual failure, which is exactly the kind that survives for years.
The three files
1. An SVG, for every modern browser
<link rel="icon" href="/favicon.svg" type="image/svg+xml">Vector, so it stays sharp at any density. Usually smaller than the PNG set it replaces, too. Every current browser supports it.
Here's the part almost nobody uses. An SVG favicon can respond to the browser's colour scheme, because the media query lives inside the file.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32">
<style>
path { fill: #212121 }
@media (prefers-color-scheme: dark) { path { fill: #FFF8E1 } }
</style>
<path d="..."/>
</svg>Dark-mode users get the light version of your mark. Light-mode users get the dark one. You shipped one file, and your charcoal logo stops vanishing into a dark tab bar. It's the best favicon upgrade available in 2026, and most sites still ship a flat PNG.
2. A 32×32 favicon.ico, for the fallbacks
<link rel="icon" href="/favicon.ico" sizes="32x32">Keep it at the site root. Some crawlers, feed readers and older tooling still request /favicon.ico blindly, without reading your HTML first. An ICO can hold 16×16 and 32×32 in one file. It's the only legacy artefact worth keeping, and it costs a couple of kilobytes.
3. A 180×180 apple-touch-icon.png, for iOS
<link rel="apple-touch-icon" href="/apple-touch-icon.png">180×180 is the current iPhone home-screen size, and iOS downscales cleanly from it for everything smaller. No sizes attribute needed if you only ship one. One catch: iOS ignores transparency here and composites onto black. Give this one a solid background unless you like the look of a logo floating in a void.
If you'd rather not make these by hand, the favicon generator takes one image and returns exactly this set, including a real multi-size ICO and the Apple touch icon already flattened.
Optional fourth: the manifest icons
If your site is installable, the web app manifest wants its own set:
{ "icons": [
{ "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
]}If it isn't installable, skip these. Shipping PWA icons for a site with no manifest is cargo cult.
Where this goes wrong in Next.js
Since a decent share of the people hitting this question are on Next.js: the App Router handles favicons through file conventions rather than manual tags. Drop icon.svg, favicon.ico, and apple-icon.png into app/ and the framework generates the tags for you, with a cache-busting hash.
The trap is doing both. Put files in app/ and hand-write tags in your layout, and you get two sets of declarations with browsers picking unpredictably between them. Same class of mistake as duplicate title tags. Nothing errors, the page looks fine, the wrong one wins.
Pick the file convention or pick manual tags.
For the full picture of how the App Router handles head tags, meta tags in Next.js: the App Router Metadata API end-to-end covers the rest of the surface.
Why your new favicon isn't showing up
Three culprits, in the order they're usually guilty.
Browser cache. Favicons are cached hard, and separately from your normal page cache. A regular refresh won't shift it. Load the icon URL directly (/favicon.ico) and hard-refresh that, or just test in a private window.
Google's own timeline. Google recrawls your homepage to pick up favicon changes, on its own schedule rather than yours. The documentation is explicit that crawling can take from several days to several weeks. Requesting indexing on the homepage via URL Inspection is the only lever you have, and it's a nudge rather than a button.
You changed the file but not the path. If your icon lives at the same URL, every cache between you and the user has a reason to keep serving the old bytes. Changing the filename is the reliable fix. That's exactly why the Next.js file convention hashes them for you.
If it's the social preview that's stale rather than the tab icon, that's a different cache with different rules. Here's how to fix that.
The three-line summary: - Ship an SVG, a 32×32 ICO, and a 180×180 apple-touch-icon. That's every surface that matters - Google wants square and larger than 48×48. The "multiple of 48" rule isn't in its docs - Put a prefers-color-scheme query inside the SVG. One file, correct in both themes
Check yours with the favicon checker, or build a fresh set with the favicon generator.
Sources (retrieved 2026-09-06): - Define a favicon to show in search results — Google Search Central (8×8 minimum, larger-than-48×48 recommendation, supported formats and rel values, crawl timing) - How to Favicon in 2026 — Evil Martians (the minimal-file-set approach and 32×32 reasoning) - Favicon — MDN Web Docs (the historical 16×16 definition)