Why a favicon matters more than it looks
A favicon is the small icon that shows up in a browser tab, next to a bookmark, in a browser history list, and on a phone's home screen when someone saves your site as a shortcut. It's easy to treat as an afterthought, but it's also one of the most visible pieces of branding your site has, simply because of how often it appears.
A missing or broken favicon is one of those small details that quietly signals an unfinished site. Visitors may not consciously notice a good favicon, but they will notice a generic blank page icon sitting next to a dozen properly branded tabs from other sites. It's a tiny thing that adds up to a trust signal.
It also matters more than it used to. Browsers now show favicons in tab groups, in address bar suggestions, and in reading lists. Mobile operating systems use them for home-screen shortcuts. A favicon set that only covers "the basic case" leaves gaps in all of these newer surfaces.
Think about how often a user actually reads your page title versus how often they just glance at the row of tabs at the top of their browser to find your site again. With ten tabs open, nobody is reading text. They're scanning icons. If yours is a gray blank square, you're the tab that gets closed first when someone is cleaning up their browser.
There's also a practical side that has nothing to do with branding. Some browsers and crawlers request /favicon.ico automatically on every single page load, whether or not you've linked to it. If that request 404s, it's a wasted round trip on every visit, and some server logs fill up with a steady stream of those failed requests. Fixing your favicon setup cleans that up too.
The sizes browsers and devices actually expect
There isn't one single favicon size. Different browsers, operating systems, and app contexts each request a specific size, and if you don't provide it, they either stretch a size you do have or fall back to nothing at all. Here's what actually gets used:
- 16x16 and 32x32. The classic browser tab and bookmark bar sizes. 16x16 is what most desktop browser tabs render at; 32x32 covers higher-density displays and the Windows taskbar.
- 180x180. The Apple touch icon size, used when someone adds your site to their iOS home screen. Without this, iOS falls back to a screenshot of your page, which almost never looks intentional.
- 192x192 and 512x512. Used by Android and by Progressive Web App manifests. The 512x512 size is also what gets used for app splash screens if your site is installed as a PWA.
- favicon.ico. A legacy multi-resolution format that some older browsers and some crawlers still look for directly at
/favicon.ico, regardless of what your HTML tags say. It's cheap insurance to include one.
None of these sizes are optional if you want consistent branding everywhere. Skipping the 180x180 size, for example, is one of the most common gaps, since it's invisible on desktop and only shows up the first time someone tries to save your site to their iPhone.
It helps to think of these sizes as belonging to two different jobs. The 16x16 and 32x32 pair is about identification: helping a human recognize your site at a glance in a crowded browser. The 180x180, 192x192, and 512x512 sizes are about installation: they're what gets used when your site starts behaving like an app icon on someone's device. Get the first job wrong and your site looks unfinished. Get the second job wrong and your brand looks broken the moment someone tries to treat your site as more than a page they visit once.
Some setups also call for a site.webmanifest file, which is a small JSON file that lists your Android and PWA icon sizes in one place so mobile browsers can find them without guessing. It's not strictly required for every site, but if you want your site to behave well when added to an Android home screen, it's worth including alongside the image files themselves.
The HTML tags that actually load them
Having the image files sitting in your project folder does nothing on its own. Browsers only pick them up if you point to them with <link> tags in your page's <head>. This is the step people skip most often, usually because they assume dropping a file named favicon.ico in the root is enough.
A complete set looks something like this:
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png"><link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png"><link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png"><link rel="icon" type="image/png" sizes="192x192" href="/android-chrome-192x192.png"><link rel="icon" type="image/png" sizes="512x512" href="/android-chrome-512x512.png">
The favicon.ico file at the root of your domain doesn't need a link tag at all; browsers check that path automatically as a fallback. But every other size needs an explicit tag, in the right place, pointing at the right file path. Get the path wrong (a common mistake when a site is deployed under a subfolder) and the browser silently shows nothing instead of erroring.
These tags all belong inside <head>, near your other meta tags, and order doesn't matter much as long as they're all present. What does matter is that the href paths actually resolve. If your site lives at example.com/app/ instead of the domain root, a favicon path of /favicon-32x32.png will point to the wrong place unless that file is actually served from the root. This trips up a lot of single-page apps and subfolder deployments, and it's worth checking directly in your browser by visiting the image URL and confirming it loads before assuming the tags are the problem.
Designing an icon that works at 16x16
This is the part that trips up a lot of otherwise well-designed brands. A full logo, with a wordmark, fine detail, or subtle gradients, usually looks great at 200px and turns into an unrecognizable smudge at 16x16. What reads clearly on a business card does not automatically read clearly in a browser tab.
A few things that actually work at favicon scale:
- A single bold letter. Your brand's initial, in a heavy weight, on a solid background color, is often more legible than your full logo shrunk down.
- A simplified icon mark, not the full logo. If your logo has an icon plus wordmark, use just the icon, and simplify it further if it has fine detail.
- High contrast. Thin lines and subtle color differences disappear at small sizes. Bold shapes and strong contrast survive.
- Test it small before committing. Shrink your candidate icon down to an actual 16x16 preview and look at it, not just the full-size version, before finalizing.
If you can't tell what your icon is at actual browser-tab size, neither can anyone else. Design for 16x16 first, then scale up, not the other way around.
Color choice matters here too. A favicon usually sits on a light-colored browser tab bar in light mode and a dark one in dark mode, so an icon that relies on a pale color against a white background can vanish depending on the user's browser theme. A background fill, rather than a transparent icon floating on nothing, tends to hold up better across both.
It's also worth designing the icon as its own asset rather than as an automatic crop of your existing logo. A quick square crop of a wide logo often centers the wrong part of the mark, or clips it awkwardly. Spend the extra ten minutes to lay out a dedicated square version, even if it reuses the same colors and shape language as your main logo.
Generating every size from one image, for free
Manually resizing one source image into five or six different exact pixel dimensions, then writing out the matching HTML tags by hand, is exactly the kind of repetitive task worth automating. You want one clean source image in, and every required file plus the ready-to-paste HTML out.
That's what our own free Favicon Generator does. Upload one image and it produces every size browsers and devices expect, packaged up along with the exact <link> tags to paste into your <head>. There's no sign-up, no file limit, and nothing is uploaded to a server you don't control since the resizing happens in your own browser.
Start with a simplified, high-contrast source image as discussed above, and let the generator handle the size math and the markup.
This matters more than it sounds like it should, because resizing an icon down by hand in a general-purpose image editor often introduces soft, blurry edges at the smaller sizes, exactly the problem a good favicon needs to avoid. A generator built specifically for this job applies sharper resampling at each target size, which is the difference between a crisp 16x16 icon and a mushy one. Doing this once, correctly, for every size at the same time also means you never end up with a mismatched set where the 512x512 icon looks different from the 32x32 one because they were exported separately, weeks apart, from slightly different source files.