Emoji Favicon via Inline data-URI SVG — Zero HTTP Reque...

I keep seeing this on small Netlify sites and indie launches and I think more people should know about it. The whole favicon stack, the 16x16, the 32x32, the 180x180 Apple touch icon, the multi-resolution .ico, the manifest.webmanifest references, the <link> salad in your <head>, all of it, can collapse into one line:

<link rel="icon" type="image/svg+xml"
      href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>🏆</text></svg>" />

Pick a different emoji, you have a different favicon. There is no separate file, no extra HTTP request, no design pass, no ImageMagick. The SVG renders crisp on every screen because vectors don't pixelate. The browser caches it with the page itself.

I first saw this on a tribute site Lea Verou wrote up in 2024, and ran into it again last week on a public Netlify-hosted page where it was the only branding asset on the page. It worked beautifully there. The whole site was a single React bundle, an <div id="root">, and a 🏆 favicon. That was the brand mark.

What's actually happening

The browser sees a <link rel="icon"> with a data: URI body. Instead of fetching a separate file, it parses the URI inline. The body is an SVG document with a single <text> element rendering one emoji. The viewBox defines a 100×100 unit canvas. The font-size: 90 plus y: 0.9em centers the glyph vertically.

The percent-encoding (%22 for ") is required because URIs cannot contain raw double quotes. SVG is XML, XML wants quotes around attribute values, so you encode them. You can use single quotes for the attributes inside the SVG and skip the encoding, but most engines and copy-paste tools handle %22 better.

Why use it

Zero HTTP request. The favicon is part of the HTML response body. There is no separate file to fetch, no race condition where the page renders before the favicon, no third-party CDN to depend on.
Sharp at every resolution. Browsers render SVG at the requested device-pixel size. No 16x16 vs 32x32 vs 180x180 question.
One-line iteration. Want to test five different emoji as your brand mark? Edit one string, refresh, done. No design tool round-trip.
No build pipeline. No favicons npm package, no realfavicongenerator.net upload, no folder of pre-generated PNGs to commit.

When NOT to use it (the limits I had to learn the hard way)

The pattern is real but it isn't complete. Here's where it falls short:

iOS home-screen icon. Safari on iOS still prefers a 180×180 PNG apple-touch-icon. If your visitors save your site to their home screen and you care how it looks there, you need the PNG. The data-URI SVG is ignored.
Android home-screen / PWA icon. Same story. The manifest.webmanifest icons array wants 192×192 and 512×512 PNGs. Without those, "Add to home screen" gets a generic placeholder.
Old Windows browsers and feed readers. A surprising number of feed readers, link-preview bots, and corporate-IE installs only look for /favicon.ico. They don't see the <link> tag, they request the path directly. If you don't serve a real favicon.ico, you get a 404 in those clients.
Crawler / archive thumbnails. The Wayback Machine, Reddit, Discord, Slack, and a few RSS aggregators bake the favicon into their preview cache. Some of them resolve the data-URI correctly; some of them ignore it and fall back to /favicon.ico.
Brand-design ambitions. An emoji is a glyph defined by the OS vendor's font. The 🏆 your visitor sees on iOS is a different glyph from the 🏆 they see on Android, which is different again on Windows. If pixel-level brand consistency matters, you can't use this.

The minimum-viable favicon stack for a real site

If you want the data-URI SVG benefit AND coverage for the edge cases:

<!-- Modern browsers: scalable, zero-request -->
<link rel="icon" type="image/svg+xml"
      href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>🏆</text></svg>" />

<!-- Legacy browsers, IE, Windows shortcuts, Wayback fallback -->
<link rel="icon" href="/favicon.ico" sizes="any" />

<!-- iOS home-screen (180x180 PNG) -->
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />

<!-- PWA manifest (Android home-screen, install prompt) -->
<link rel="manifest" href="/manifest.webmanifest" />

You commit one favicon.ico, one apple-touch-icon.png, and one manifest.webmanifest. The data-URI SVG handles every modern desktop and mobile browser at zero request cost. The fallbacks cover the long tail.

A small generator you can paste anywhere

If you want a slightly cleaner SVG body, drop the percent-encoding and use single quotes inside:

<link rel="icon" type="image/svg+xml"
      href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'><text y='.9em' font-size='90'>🏆</text></svg>" />

Same result, more readable in source. Some older URL parsers prefer the percent-encoded version, so for maximum compatibility stick with %22. Both work in every browser shipped since 2018.

You can also do non-emoji glyphs: a single Unicode character, a Material Symbol, even a tiny <path> if you want a real custom mark inline. Once you're inside the SVG, anything goes. The total budget is the URL length limit (~64KB in modern browsers, comfortably more than you need for a 100×100 canvas).

What this connects to

Tiny technical wins like this compound. Every removed HTTP request shows up in your Largest Contentful Paint score. Every "in-the-HTML" asset is one fewer thing the browser has to negotiate, one fewer thing a CDN can serve stale, one fewer thing that breaks when DNS hiccups. None of it matters individually. All of it matters in aggregate.

I covered domain setup, hosting, and the minimum-viable launch checklist in The $97 Launch, the first book in the Digital Empire trilogy. Chapter 6 is about the absolute minimum a launched site needs to look credible. The data-URI SVG favicon is not in the chapter (the book predates the technique going mainstream), but it fits the spirit of it: do the thing that's good enough, ship, iterate.

Fact-check notes and sources

SVG favicon support across browsers (Chromium, Firefox, Safari): caniuse.com — SVG favicons.
data-URI scheme spec: RFC 2397.
Apple touch icon size guidance: Apple Developer — Configuring web icons.
Web app manifest icon requirements: W3C Web App Manifest spec, icons section.
Lea Verou's 2024 writeup of the percent-encoded SVG-favicon pattern is the cleanest reference I've found: search "lea verou emoji favicon svg" if you want the original post.

This post is informational. Pick the favicon strategy that matches the audience your site actually has.

The Zero-Request Favicon: Emoji-as-data-URI-SVG You Can Ship in 60 Seconds