Favicon Format: PNG vs ICO vs SVG — Which Should You Use?

Which format should a favicon be? The honest answer is all three, because PNG, ICO and SVG aren't competing for the same job. Each one covers a gap the other two leave:

• PNG for the specific sizes: browser tabs, the Apple touch icon, Android icons. It renders everywhere.
• ICO for the favicon.ico file at your site root, which bundles 16, 32 and 48px into one file and answers requests from tools that never read your HTML.
• SVG for a single small file that stays sharp at every size and can even change colour in dark mode.

Here's what each format does well, where it falls short, and how they fit together.

PNG: the universal baseline

PNG is the format almost every current <link rel="icon"> tag should point to. It's a raster format, meaning each file is locked to one fixed resolution, so a full set means exporting several files — 16×16, 32×32, 180×180, 192×192, 512×512, and so on, one per size you need. That's more files to manage than a single SVG, but in exchange you get support that's essentially universal: every browser, every OS, every context that reads a <link> tag renders PNG correctly, with no surprises.

PNG also supports transparency, which matters for the browser-tab and Android-icon sizes where a transparent background lets the icon sit naturally against whatever chrome color surrounds it. The one place transparency actively hurts is the Apple touch icon — iOS fills transparent areas with solid black, so that specific 180×180px export should be flat with an opaque background baked in, not transparent like the rest of the set.

Generating a PNG set from any source image — a logo, a screenshot, whatever you've got — is straightforward, which is part of why it's the safe default. See the favicon size guide for the exact list of PNG sizes a modern site needs.

SVG: small, sharp, not universal

SVG is a vector format, so a single file scales cleanly to any resolution on any pixel density without separate exports per size. For a simple logomark — a wordless icon, a geometric shape, a monogram — that means one small file replacing what would otherwise be five or six PNGs, often at a fraction of the total file size.

The catch is that SVG support for favicons isn't universal the way PNG's is. Some older tools and certain crawlers still expect a raster fallback and won't render an SVG favicon at all, which is why it should always sit alongside a PNG set rather than replace it. SVG can also render inconsistently if the file references external fonts, embedded scripts, or anything dynamic — a favicon SVG should be kept as pure, static vector shapes. Treat it as a bonus layer for browsers that support it, not the whole strategy.

ICO: the legacy fallback container

ICO isn't a general-purpose image format you'd pick for anything outside this one job. What makes it useful specifically for favicons is that it's a container — a single .ico file can bundle multiple resolutions (typically 16, 32, and 48px) together, and the browser picks whichever fits.

Its real purpose today is narrower than it used to be: answering requests for /favicon.ico at the domain root. Browsers make that request when a page declares no icon, and feed readers, link-preview bots and many crawlers make it without reading your HTML at all. Our deep dive on whether .ico is still needed covers this in detail. Short version: yes, it's still needed, and without it every one of those requests is a 404.

Comparison table

Format	Best for	Browser support	File size	Notes
PNG	Defined-size <link> icons (16–512px)	Universal	Small, one file per size	Needs a full set of exports; supports transparency
SVG	Crisp scaling from one file	Wide but not universal	Very small, single file	Best for simple static vector marks; not a full replacement for PNG
ICO	The /favicon.ico fallback path	Universal (that's its whole job)	Small, multi-size container	Legacy format; not useful for anything outside this one path

The practical recommendation

Don't pick one — ship all three together:

1. A real multi-resolution favicon.ico at the domain root, so the automatic fallback request finds something real.
2. A full PNG set at the sizes browsers, iOS, and Android actually request via <link> tags and the manifest.
3. An SVG on top, if your mark is a simple vector shape, for crisp rendering wherever it's supported.

Building this by hand means exporting the same source art at half a dozen sizes, packing several of them into an .ico container correctly, and keeping the SVG clean of anything that could break its static rendering. The converter does all three from one source image in a single pass — correctly sized, not stretched — which is the fastest way to end up with a complete, correctly formatted set instead of guessing which single format to commit to.