The 25-file favicon package I deleted
The first favicon generator I ever used handed me a zip with more than twenty files and a block of markup longer than my homepage content. Tile colors for Windows 8. Precomposed icons for iPhones that stopped receiving updates a decade ago. Five intermediate PNG sizes no modern browser has requested from my server since I started checking the logs. I shipped all of it, because the internet told me to, and it sat there as cargo-cult clutter for two years.
When I rebuilt this site I did the opposite: started from zero and added files only when something visibly broke without them. The final count was five files and three lines of markup, and every browser, tab, phone home screen, and search result I can test looks right. Here is the short list, what each piece is for, and the pile you can safely skip in 2026.
The five files that cover everything
This is the complete set I ship on every project now. Nothing here is speculative; each file has a specific consumer that actually requests it.
That is genuinely the whole package. MDN's rel=icon documentation, linked below, backs up the minimalism: browsers pick the best match from what you declare, and modern ones are content with very little.
- favicon.ico at the site root, containing 16x16, 32x32, and 48x48 layers: the universal fallback that old agents and various tools request by convention, markup or not
- One SVG icon, declared with rel=icon: sharp at every size in modern browsers and the key to dark mode, more on that below
- apple-touch-icon.png at 180x180: what iOS uses when someone adds your site to their home screen
- icon-192.png and icon-512.png, referenced from the web manifest: what Android and installed PWAs use for home screen icons and splash screens
ICO vs PNG vs SVG: which format wins?
The honest 2026 answer is all three, each in its lane. The ICO format survives because it is a container: one file carrying several pixel sizes, parked at the root where everything expects it. It is legacy, and it is also the single most reliably fetched icon file on the web, so it stays. If you would rather not touch the format yourself, the favicon generator builds the multi-size ICO and the whole companion set from one uploaded image, which is the entire reason I built it.
SVG is the modern star: one vector file, sharp on every display density, tiny on disk, and capable of carrying its own styling. PNG remains the workhorse for the places that require raster, meaning the apple-touch icon and the manifest icons. If you only remember one rule: SVG for the tab, PNG for home screens, ICO for the ghosts.
Dark-mode tabs: why your icon disappears
Browser tab bars now follow the operating system theme, which means your near-black logo sits on a near-black tab for half your visitors, and I ran that way for months before a reader mentioned my site had no icon. It had one. It was just invisible in the dark, which is worse than absent because you never see the problem on your own light-mode machine unless you go looking.
The clean fix is the SVG favicon: since SVG can embed CSS, the icon can restyle itself when the browser reports a dark interface, swapping dark strokes for light ones automatically. The blunt fix, if you would rather not maintain a self-aware icon, is designing a mark that survives both themes: a solid colored shape with contrast against both white and near-black backgrounds. When I rebuilt mine, I pulled the brand colors with the color palette extractor and picked the one mid-brightness accent that held up on both. Either fix works. Test both themes, because the failure mode is silent.
What can I skip in 2026?
Everything on this list came out of my own deleted pile, and nothing broke. The general principle: if the file's target platform no longer exists or its consumer scales another file perfectly well, the file is clutter.
The one habit worth keeping from the old maximalist era: generate the big sizes from a genuinely sharp source. Everything flows down from one clean 512 or larger master image.
- browserconfig.xml and msapplication tile markup: for live tiles on retired Windows versions
- The ladder of legacy apple-touch sizes, 57 through 152: modern iOS scales the 180 down fine
- Safari's mask-icon pinned tab file: deprecated, modern Safari uses your regular icons
- Intermediate PNGs like 96x96 and 128x128: nothing asks for them when proper sizes exist
- Any keyword-stuffed markup block a generator dated before 2020 tells you to paste
Making the icon legible at 16 pixels
The design mistake I made twice: shrinking the full logo, wordmark and all, into the favicon. At 16 pixels a wordmark is not text, it is lint. The favicon needs to be a mark: one letter, one shape, one simplified symbol, drawn with fat strokes and generous negative space. If your logo has a distinctive element, crop to that element rather than miniaturizing the whole thing.
My pipeline for the raster pieces is short. Master image at 1024, cut down with the image resizer to 512, 192, and 180, then everything through the image compressor, because the 512 manifest icon is the one file here where bytes add up and a fat splash-screen icon is pure waste. The whole set weighs less than one photo thumbnail when done right.
Testing: the cache will gaslight you
Favicon caches are the stickiest caches in the browser. You will replace the file, refresh twelve times, clear site data, question the deploy, and the old icon will smile back from the tab. This is normal and it has wasted afternoons of my life. The sane workaround during development is changing the filename or adding a version query to the icon link, since a URL the browser has never seen cannot be cached. Roll the version, see the new icon instantly, move on.
My release checklist: tab icon in light and dark themes, add-to-home-screen on one iPhone and one Android, the installed-app icon if a manifest exists, and a search for the site on Google, since search results render your favicon beside the listing and a broken one undercuts every snippet you worked on. The favicon is one of the two tiny preview surfaces every site ships; the other is the social share card, and that one has its own set of traps I wrote up in the Open Graph image size guide.
Questions people ask
Five files: a multi-size favicon.ico at the root with 16, 32, and 48 pixel layers, one SVG icon, a 180x180 apple-touch-icon, and 192x192 plus 512x512 PNGs referenced from your web manifest. That covers browsers, phones, and installed apps.
Keep it. Plenty of older agents, crawlers, and tools request /favicon.ico by convention without reading your markup, and one small multi-size file at the root costs nothing while quietly covering all of them.
Favicon caching is notoriously stubborn and normal refreshing often will not budge it. Change the icon's filename or add a version query string to the link tag so the browser sees a brand new URL.
Either use an SVG favicon with embedded styling that swaps colors when the browser interface is dark, or design a mark with enough contrast to survive both light and dark tab bars. Then actually test both themes, because the failure is invisible on your own setup.
Yes, search listings display your favicon beside the site name, on mobile especially. A missing or muddy icon makes every result look less legitimate, which is a strange amount of power for a 16 pixel image to hold.
