SVG favicons are the dream: one crisp vector file, scales forever, tiny payload. And in 2026 most of that dream works — but "most" is doing a lot of heavy lifting. Depending on which browser, which platform, and which non-browser tool fetches your icon, the SVG you shipped may be read, ignored, or replaced by a request for /favicon.ico you never made. Here's what actually happens, and the link stack that keeps every consumer happy.
Who reads your SVG favicon
Chrome, Firefox, Edge — all read <link rel="icon" type="image/svg+xml" href="/favicon.svg"> and prefer it over raster alternatives when declared correctly. Bonus you can't get from PNG: SVG favicons can embed CSS with media queries, which is exactly how the dark-mode Safari favicon trick swaps colors without JavaScript.
Safari on macOS — supports SVG favicons, with quirks: it historically ignored the type attribute and picked icons by sizes and order instead. Declaring both a PNG and an SVG without thinking about order leads to Safari grabbing the "wrong" one. If your icon looks right in Chrome and off in Safari, this is usually why.
iOS Safari — reads none of this. No ICO, no SVG. It only ever looks at apple-touch-icon (180×180, no transparency). If your fancy SVG "doesn't work on iPhone," it was never going to.
Not-a-browser consumers — feed readers, crawlers, chat-link previews, some enterprise tooling: a surprising number still ignore your HTML entirely and GET /favicon.ico by convention. Ship no ICO and those tools show a blank square or log 404 noise on every request.
The link stack that works everywhere
<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"> ICO is the floor every consumer can fall back to, SVG is the upgrade modern browsers take, apple-touch-icon covers iOS. Two practical notes:
- SVG with a bitmap floor beats SVG alone. The ICO costs a few KB and silences the direct
/favicon.icofetchers. - Keep the SVG small. Embedded fonts or giant path data blow up your document weight for a 16×16 render. Simplify paths before shipping — why favicons go blurry and how vector fixes it covers the sizing math.
Converting: the boring part everyone skips wrong
You have an SVG. You still need the ICO floor and the PNG ladder (16/32/192/512). Two wrong ways to do it: screenshot your icon and call it a day, or upscale a 32px export to 512px and ship mush. The right way is generating each raster size from the original vector:
- SVG → multi-size ICO directly in the browser: svg-to-ico converter
- PNG → ICO when your source is already raster: png-to-ico converter
- No SVG yet, just text or an emoji idea: the SVG favicon generator and emoji-to-favicon build the vector from scratch — all client-side, nothing uploaded.
The full size-vs-format matrix (what each platform actually reads in 2026) is in the SVG vs PNG favicon breakdown — worth bookmarking next to your deploy checklist.
Verify before you blame the browser
The fastest way to lose an hour is arguing with Safari about an icon your page never actually declared. Run the deployed URL through a favicon checker — it fetches the live page, lists every declared icon, and shows what each one resolves to. If your SVG isn't in that list, the problem is your <link> tag, not the browser.
That's the whole game: vector for modern browsers, ICO floor for everything else, apple-touch for iOS, and a checker pass before you blame anyone. Ten minutes, once per project.
