Search for favicon sizes and you will find checklists of fourteen files, most of which exist for devices discontinued a decade ago. The real list is much shorter, and one entry on it is a vector.
What you actually need
| File | Size | What it is for |
|---|---|---|
favicon.svg |
vector | Modern browsers, scales to any tab size, can adapt to dark mode |
favicon.ico |
16 and 32 | Requested directly by browsers and crawlers, no HTML needed |
apple-touch-icon.png |
180×180 | iOS home screen |
icon-512.png |
512×512 | Android install prompts, PWA manifests, and what search results use |
That is it. The long lists are legacy.
Why .ico is not just a renamed PNG
An ICO file is a container. It holds several images at different sizes, and the browser picks the one it needs. That is why you cannot rename icon.png to favicon.ico and expect it to work reliably, and why an ICO generator takes one image and produces a multi-size file rather than simply changing the extension.
It is also still worth shipping in 2026 for one specific reason: browsers and crawlers request /favicon.ico at the site root directly, with no HTML link tag involved. If the file is absent you get a 404 in your logs on every cold visit, and some contexts will show a blank icon even though your SVG is declared perfectly.
The SVG is the one doing most of the work
A single SVG covers every size a browser tab needs, because it is drawn at whatever resolution is asked for. It is usually the smallest file of the set.
It has one property the raster icons cannot match:
<style>
@media (prefers-color-scheme: dark) {
.logo-mark { fill: #fff; }
}
</style>
Media queries inside the SVG let the icon respond to the browser's theme, so a dark logo stops disappearing against a dark tab strip. This is worth doing and almost nobody does it.
The catch is that the SVG must be self-contained. No external stylesheet, no remote font, no linked image. If the icon uses text, convert it to paths, because the font will not be available.
Design the small one separately
This is the part that gets skipped, and it is the part that decides whether the icon is any good.
At 16 pixels you have 256 pixels in total. A logo with a wordmark, a gradient and a thin outline turns into a grey smudge. Every recognisable favicon solves this the same way: a single bold shape, high contrast, no text beyond perhaps one letter.
So do not resize your logo to 16px and accept the result. Look at it at actual size, and if it is unreadable, draw a simplified mark for the small sizes. The SVG can carry the detailed version for large rendering while the ICO carries the simplified one.
Two practical points while you are there. Keep some padding inside the canvas, because browsers crop tight to the edges and a shape touching the boundary looks cramped. And use a transparent background rather than white, unless the mark needs a plate behind it.
Wiring it up
<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">
Browsers that understand SVG use it; the rest fall back to the ICO. The 512px PNG is referenced from the manifest rather than from a link tag.
Producing the set
From one high-resolution square source:
- Export or convert to SVG, and make sure it has no external dependencies.
- Produce 180×180 and 512×512 PNGs by resizing the source, not by upscaling a small file.
- Build the ICO with 16 and 32 included, from the simplified mark if you drew one.
- Look at the 16px version at 16px on both a light and a dark tab strip.
Step four is the only one that is not mechanical, and it is the one that matters.