ICO vs PNG vs SVG Favicons: What Actually Renders in 2026

Ship a site with one icon file, a clean SVG, and Chrome renders it perfectly. So does Firefox. Then someone opens the site on an iPhone, adds it to the home screen, and gets a gray rounded square with a capital letter sitting where the logo should be.

Nothing is broken. The site has one file, and iOS was never going to use it.

Favicon advice ages badly, and much of what ranks for this question was written before September 2025, when Safari's position on SVG changed. What follows is checked against the specs and support tables as of 09-Aug-2026.

What the three formats are for

.ico is a Windows container from the 1990s. One file holds several bitmaps at different sizes and the browser picks the one it wants. Per the format documentation, it tops out at 256x256 and has been able to store PNG-compressed frames since Windows Vista. Nobody designs in ICO; you export to it.

.png is a fixed-resolution bitmap with real transparency. Every browser and every operating system reads it, and it is the only format Apple's docs commit to for home screen icons.

.svg is vector. One file at any size, usually smaller than the PNG it replaces, and it stays crisp on a display you haven't bought yet. It's also the newest arrival in favicon support, which is why so much of the advice about it is out of date.

For the longer version of that tradeoff outside the favicon context, the PNG vs SVG comparison covers where each one belongs across a brand kit.

What renders where

Support data from caniuse, checked 09-Aug-2026: SVG favicons sit at roughly 90.5% of global traffic. Google's favicon documentation says "any valid favicon format is supported", requires a square image of at least 8x8px, recommends going above 48x48, and only ever shows one favicon per hostname. It never names SVG specifically, which is why that cell says undocumented rather than supported. Your root ICO covers you in search either way.

Safari changed its mind in September 2025

This is the part most favicon advice still gets wrong, including a post I wrote earlier on turning a logo into a browser icon.

Safari ignored SVG favicons for a decade. That ended with Safari 26.0, released 15-Sep-2025. The WebKit release post puts it plainly: "Safari 26.0 now supports the SVG file format for icons everyplace there are icons in the interface, including favicons." Safari now rasterizes your SVG itself at whatever size it needs, for tabs, the start page, Reading List, and web app icons. The same release added data URL icons, so a small icon can be inlined as code.

Caniuse marks Safari 26.0 and iOS Safari 26.0 as the first supporting versions. Every Safari before that, meaning 18.x and down, doesn't fall back to nothing when it hits your SVG. It falls back to whatever else you gave it, which is the argument for still giving it something.

Two conditions attach to the SVG. It has to be served with the image/svg+xml MIME type or browsers refuse it, and Chromium loads it in SVG secure static mode, so scripts inside the file do nothing and any SMIL animation is applied at document start time, meaning you get its first frame rather than motion.

Do you still need favicon.ico

Yes, and not out of nostalgia. Browsers, crawlers, and feed readers request /favicon.ico at the site root by convention, with no <link> tag required. If the file is missing you get a stream of 404s in your logs and a blank icon in whatever asked for it. It also covers the entire pre-26 Safari install base, which is still a large share of iPhones in use, since Safari updates ride along with iOS updates and plenty of people sit on an old iOS for a year or more.

Chrome will also sometimes pick the ICO over your SVG when both are declared. The workaround, documented in Evil Martians' favicon guide, is to put sizes="32x32" on the ICO link so the browser can rank the two properly. That one attribute is why the copy-paste block below looks slightly odd.

You do not need a multi-size ICO in 2026. A single 32x32 frame is enough unless your artwork downscales badly to 16x16, in which case add the smaller frame and check it by eye.

apple-touch-icon is still the file Apple reads

MDN is blunt about this on the rel reference: iOS "does not use this link type, nor the sizes attribute" the way other mobile browsers do, and reaches for the non-standard apple-touch-icon instead.

Apple's web application configuration doc asks for PNG, 180x180 for retina iPhones, and says that if you declare no icon at all it goes looking for an apple-touch-icon file at your root. Ship one file at 180x180 and skip the iPad sizes, since iOS downscales fine.

Give the artwork a solid background color rather than transparency, because iOS composites transparent pixels onto black and a dark logo disappears into it. Leave roughly 20px of padding inside the 180 so the system corner radius doesn't clip anything. If your mark is thin or fussy, redraw it before you export; the app icon sizes reference has the full set of platform dimensions if you need them.

Since iOS 15.4 Apple will read icons out of a web app manifest, and from iOS 16.4 a site with no icon at all gets a generated monogram instead of a screenshot, per WebKit's February 2023 post. That monogram is the gray letter square from the top of this post. Where both exist, apple-touch-icon wins.

Manifest icons cover installs

The Web Application Manifest spec, Working Draft dated 23-Jul-2026, lists icons as an optional member. It is optional in the spec and required in practice if you want Chrome to offer installation, since Chromium's installability check wants a 192x192 and a 512x512 PNG before the install prompt appears.

The purpose field gets skipped more than it should. Setting it to maskable tells Android launchers they may crop your icon to whatever shape the device uses, so the artwork needs to sit inside a central circle of 409px within the 512 canvas. Without a maskable icon, Android drops your square PNG inside a white blob and it looks like a mistake.

If you're not building an installable app you can skip the manifest entirely; a brochure site doesn't need one.

Dark mode SVG favicons are a nice trick with soft support

You can put a <style> block inside an SVG and change the fill under @media (prefers-color-scheme: dark), which gives you one file that flips color with the system theme:

<style>
  @media (prefers-color-scheme: dark) { .mark { fill: #F2F1EE } }
</style>

It works, but not everywhere, and the support isn't documented in any table worth citing. Firefox has honored it since version 101. Chromium evaluates the media query when the icon loads and doesn't repaint on a live theme switch, so the change only shows up after a refresh. Safari's behavior here I couldn't confirm against a primary source, so treat it as unknown.

Build the SVG to survive being wrong about all of that. Pick a mark that reads on both a white tab bar and a dark one, then add the media query as an improvement rather than a dependency. A brand color with mid-range contrast usually beats pure black, which vanishes on dark chrome, and pure white, which vanishes on light chrome. There is more on that problem in the guide to light, dark, and transparent logo variations.

The block to copy

Three files at your site root: favicon.ico, icon.svg, apple-touch-icon.png.

<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/manifest.webmanifest">

Drop the block into <head> alongside the rest of your meta tags. Per MDN the browser picks using media, type, and sizes, and moves to the next candidate when a format turns out to be unsupported. Order is only the tiebreak: where two icons are equally appropriate, the last one wins.

What you can delete

A typical favicon bundle still ships 20-odd files. Almost all of them are dead weight now.

The 16x16 PNG is redundant next to the 32. browserconfig.xml and the msapplication-* meta tags were for Windows 8 tiles, and Windows 8 is gone. apple-touch-icon-precomposed existed to suppress the glossy overlay that iOS dropped in version 7. The mask-icon monochrome SVG was for Safari pinned tabs and has not been needed since Safari 12. The pile of apple-touch-icon sizes at 57, 60, 72, 76, 114, 120, 144, and 152 all collapse into the single 180. And rel="shortcut icon" is, in MDN's words, "non-conforming, ignored and web authors must not use it anymore".

Delete them all. Fewer files means fewer things to update when you rebrand, which matters more than the bytes saved.

The five minute version

Take the icon mark from your logo rather than the full lockup, and check it holds up at 32 pixels. Export the SVG, a 180x180 PNG on a solid background, and a 32x32 ICO. Put all three at the root, paste the four link tags, then confirm the SVG is being served as image/svg+xml. That covers every browser and platform in the table above. None of these files take an alt attribute the way an on-page logo does; logo alt text covers that separate question.

Sources checked on 09-Aug-2026: caniuse SVG favicons, WebKit features in Safari 26.0, MDN's rel reference, Google's favicon guidelines, the W3C Web App Manifest draft, and Apple's Configuring Web Applications. Browser support moves. Re-check caniuse before you rely on a number.

If you'd rather not open a vector editor for this, the Brandize favicon generator exports the set from a logo, and if you're still working out which piece of your logo survives at tab size, the website logo checklist walks through header, favicon, and footer together.