Guide

favicon.ico vs favicon.svg

Last updated 1 September 2026

These two files do different jobs, and the common advice to "just use SVG now" quietly breaks a portion of your visitors. Here is what each one is actually for.

What favicon.ico is

ICO is a container format. A single favicon.ico holds several bitmap images — typically 16, 32 and 48 pixels — and the consumer picks whichever size it needs. It dates to Windows, which is why it survives in places that have nothing to do with modern browsers.

Its real value today is that it is requested by name from your site root, often without any HTML being parsed at all. Feed readers, link-preview scrapers, crawlers and various desktop clients all do this. If /favicon.ico returns a 404, those consumers show nothing.

What favicon.svg is

SVG is vector, so one file renders sharply at 16 pixels and at 512. It is typically smaller than the PNG set, and it can carry a prefers-color-scheme rule so the icon changes colour in dark browser chrome — something a raster file cannot do.

Two requirements catch people out. The root element must declare a viewBox, or the browser has no coordinate system to scale from and the icon fails to render. And everything must be self-contained — no external fonts, no linked images. Text referencing a font the visitor does not have will silently fall back to something else, which is why faviconflow traces letters into outlines rather than leaving them as live text.

Browser support, stated honestly

Chrome, Edge and Firefox render SVG favicons reliably. Safari is where published guidance contradicts itself: current articles variously claim support since Safari 14, since 15.4, only from Safari 26, or not at all. Those cannot all be right, and we are not going to add a fifth confident number to the pile.

What is not in dispute is the consequence: if you ship only an SVG, some visitors get no icon. Since keeping the ICO costs one extra file and one extra line of HTML, the version-by-version argument does not need resolving. Ship both.

How browsers choose

Order in your <head> is not what decides it — capability is. A browser that understands type="image/svg+xml" takes the SVG; one that does not ignores that line and falls back to the ICO or a PNG. Both tags coexisting is the intended design, not a redundancy to clean up.

Two related notes: iOS home screens always use the Apple touch PNG and never the SVG, so that file is not optional either. And animated SVGs freeze on their first frame in every browser — a favicon cannot animate.

The short version

Ship favicon.ico for reach, favicon.svg for sharpness and dark mode, an Apple touch PNG for iOS, and the Android pair for home screens. That is four surfaces with four different answers, which is why a single file has never been enough.