Favicon Formats: PNG, SVG, or ICO?

The short answer

If you want one sentence: provide an SVG or PNG icon declared in your markup for modern browsers, keep an ICO at the site root as a fallback, and add an Apple touch icon plus manifest icons if your site will be saved to phone home screens.

That sounds like more work than it is, because most frameworks generate the markup from a small number of source files. The thing worth understanding is why more than one file exists at all, since the instinct is to pick a single format and be done.

The reason is that the same little image gets used in places with very different requirements. A browser tab needs roughly 16 pixels. A bookmark bar or history entry uses something slightly larger. A Windows desktop shortcut wants up to 256. An iPhone home screen wants a large square that will be placed on a coloured tile and rounded by the operating system. No single file serves all of those well.

Can a favicon be a PNG?

Yes. This is one of the most common questions about favicons and the answer has been yes in every current browser for many years. A PNG declared with a link element and the icon relation works exactly as you would expect.

PNG is a good choice for the browser icon because it supports full alpha transparency including soft antialiased edges, it is lossless so your mark stays crisp, and its support is effectively universal. For a mark that is a photograph or has subtle shading, it is the practical choice.

The one thing PNG cannot do is scale. A 32-pixel PNG displayed at 48 pixels is upscaled and looks soft, which is why people supply several PNG sizes, or an ICO, or an SVG. If you supply only one PNG, make it large enough for the biggest use you care about and let browsers downscale, rather than small enough that anything has to upscale it.

What each format actually gives you

ICO is a container holding several complete raster images at different sizes in one file. Software picks whichever size suits its slot rather than rescaling a single source. Its enduring advantage is not technical quality but behaviour: browsers request /favicon.ico from the site root automatically, without any markup at all, so a site with an ICO there always has a working icon even if its link tags are wrong or missing.

PNG gives you lossless raster with full transparency, and you can supply as many sizes as you want via separate link elements. It is the workhorse — simple, universally understood, and the right answer for most marks.

SVG gives you something neither raster format can: it is resolution-independent, so one file is sharp at every size and on every display density, and it is usually tiny for a flat mark. It can also respond to the browser's colour scheme, which is genuinely useful — an SVG favicon can render dark on a light tab strip and light on a dark one, using the same media query mechanism as the rest of your CSS. A PNG or ICO is fixed; whatever colours it was saved with are the colours it has.

The SVG caveat is that it only suits artwork that is genuinely vector — flat shapes, a letterform, a simple geometric mark. A photograph or a complex illustration should not be an SVG, and tracing a raster logo into one produces an approximation rather than a clean file.

Sizes that actually matter

The browser tab icon renders at around 16 pixels, sometimes doubled on high-density displays. That is the size your mark must survive, and it is the size at which almost every favicon failure happens.

32 pixels covers bookmark bars, some tab rendering, and various list views. 48 is used by Windows in some contexts. 180 is the conventional size for an Apple touch icon, which iOS uses when a site is added to the home screen. 192 and 512 are the sizes a web app manifest typically declares for Android home screens and app listings.

You do not need to agonise over this list. Supply a large square source — 512 pixels is ample — and let your framework or an icon generator produce the derivatives. The sizes are conventions rather than hard requirements, and the consequence of missing one is usually a slightly soft icon in one context, not a broken site.

What you should agonise over is the design at 16 pixels, because no amount of correct file plumbing rescues a mark that is illegible at tab size.

Why a bigger file does not fix an unclear favicon

When a favicon looks like a smudge, the instinct is to supply a higher-resolution source. It almost never helps. Downscaling to 16 pixels averages large areas of the source into single output pixels, so a 1024-pixel source and a 256-pixel source produce near-identical results at tab size.

What changes the outcome is changing what is being averaged. A thin two-pixel stroke in a 512-pixel design occupies a fraction of a pixel at tab size and vanishes entirely. Making that stroke proportionally thicker is a design change, and it is the one that works.

The practical rules: use one shape rather than three, drop the wordmark and keep the symbol, raise the contrast, and crop tight so the mark fills the canvas instead of floating in transparent margin. If your logo is a company name, consider a single initial — illegible initials are still better than illegible words.

This is also where SVG has a real edge for simple marks. Because it is drawn rather than sampled, a vector mark stays crisp at 16 pixels in a way a downsampled raster cannot.

A set that covers everything

A reasonable complete set is four things: an ICO at the site root for automatic requests and legacy contexts, an SVG or PNG icon declared in markup for the browser tab, a 180-pixel PNG as the Apple touch icon, and a web app manifest declaring 192 and 512 pixel PNGs for Android and installable contexts.

If that feels excessive for a small site, the honest minimum is an ICO at the root plus a single PNG icon in markup. Everything else degrades gracefully — a site without an Apple touch icon still works, it just gets a less attractive home-screen tile on iOS.

Do not hand-maintain the link tags if your framework generates them. Next.js, for example, picks up icon files placed in the app directory and emits the correct markup itself. Hand-written tags that disagree with generated ones produce confusing results where the browser picks something you did not intend, and the conventions change often enough that a copied snippet from a few years ago is frequently wrong.

For the Apple touch icon specifically, avoid transparency. iOS composites it onto a tile, and transparent areas come out black rather than taking the tile colour. Give that one a solid background.

Why your new favicon will not appear

This is the single most reported favicon problem, and it is almost never a broken file. Browsers cache favicons far more aggressively than page content, and a cached icon survives an ordinary refresh, a hard refresh in some cases, and sometimes a browser restart.

Work through this order. Open the icon's URL directly — if the new icon appears there, the file is fine and you have a cache problem rather than a conversion problem. Then try a private or incognito window, which usually bypasses the cached entry. Then clear site data for your domain specifically.

If you need certainty, change the filename. A new path forces a fresh request, and it is the only approach that reliably defeats the cache. Appending a query string sometimes works and sometimes does not, because favicon caching does not always respect query parameters the way page caching does.

Also confirm you are testing what you think you are. A site with both an ICO at the root and link tags in the markup may be serving an icon from whichever source you did not update.

Testing before you ship

Look at it in an actual browser tab, at actual size, next to several other tabs. That is the environment the icon exists in, and a mark that looks fine alone can be indistinguishable from a neighbour in context.

Check both browser themes. A dark mark with a transparent background disappears against a dark tab strip, and this is easy to miss when your design tool has a white canvas. If you are using an SVG, this is where you can make it adapt; if raster, pick a colour with contrast against both, or add a light shape behind the mark.

Bookmark the page and look at the entry, since bookmark lists often render the icon at a different size than the tab. If the site may be saved to a phone home screen, do that too and check the tile.

Finally, check it on a high-density display if you have one. An icon that was supplied at only 16 pixels will look noticeably soft where a 32-pixel version would have been used.