Data URI (base64) Favicons
A data URI favicon embeds the image directly in the link tag as base64 text (href="data:image/png;base64,...") instead of pointing to a file, which removes one HTTP request. It works for the browser tab, but it breaks everywhere that fetches an icon by URL: /favicon.ico requests, apple-touch-icon, manifest icons, crawlers and link unfurlers. So it's not a substitute for real files.
What it buys, and what it costs
Inlining the icon as base64 saves one request: the image travels inside the HTML, so the browser doesn't fetch a separate file for the tab. For a tiny icon on a latency-sensitive page that can look appealing.
The problem is everything that doesn't read your HTML. A crawler or link unfurler requesting /favicon.ico by path gets nothing. iOS wants a real apple-touch-icon file; Android reads files listed in the manifest. None of those can use an icon that only exists as text inside one link tag, and the base64 blob bloats every HTML response it's on.
What it looks like
<link rel="icon" href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." />Fine for the tab, invisible to anything that requests an icon by URL.
Data URI favicon FAQ
Can I use a base64 favicon?
For the browser tab, yes. But it won't satisfy /favicon.ico requests, apple-touch-icon, the manifest, or crawlers, so on a real site it can only supplement real files, not replace them.
Does an inline favicon work on iOS home screens?
No. iOS home screens use the apple-touch-icon, which must be a real file it can fetch. A data URI in a favicon link does nothing for the home screen.
Is a data URI favicon good for performance?
It removes one small request but embeds the encoded image in every HTML response that carries it. For an icon that's cached hard after the first load anyway, the saving is usually negligible and the bloat isn't.