Favicon History: How a Tiny Icon Became Essential to the Web
That little 16x16 pixel icon sitting in your browser tab has a story most web developers never hear. It started as a clever hack by Microsoft engineers, became a battleground in the browser wars, and evolved into a critical piece of modern web identity that now spans dozens of sizes and formats.
Understanding favicon history isn't just trivia—it explains why we deal with ICO files in 2024, why Apple Touch Icons exist separately from regular favicons, and where this technology is heading next. Let's trace the complete evolution of the web's most overlooked design element.
The Birth of the Favicon: Internet Explorer 5, March 1999
The favicon was born in Microsoft's Internet Explorer 5, released on March 18, 1999. But the motivation wasn't user experience—it was server analytics.
Here's the original idea: when a user bookmarked (or "added to Favorites" in IE terminology) a webpage, the browser would automatically request a file called favicon.ico from the website's root directory. Website administrators could then check their server logs to count how many times favicon.ico was requested and use that number to estimate how many people had bookmarked their site.
It was a tracking mechanism disguised as a visual feature.
The implementation was brilliantly simple. No HTML tags required—IE5 would just look for /favicon.ico at the root of any domain. If it found one, it displayed the icon next to the bookmark. If not, it showed a generic page icon.
Why the ICO Format?
Microsoft chose the ICO format because it was already the standard for Windows application icons. ICO files had a useful property: they could contain multiple images at different sizes and color depths within a single file. This meant a single favicon.ico could include a 16x16 version for bookmarks and a 32x32 version for other uses.
The format dates back to Windows 1.0 in 1985. By 1999, it was battle-tested, well-documented, and every Windows developer already had tools to create ICO files. For Microsoft, using ICO was the obvious choice.
This decision would shape favicon development for the next 25 years. Even today, ICO remains the only format that works in truly ancient browsers, and the "favicon.ico in the root directory" convention persists as a fallback that still works.
The Browser Wars Shape Favicon Standards (2000-2003)
Netscape Navigator, Microsoft's primary competitor, didn't initially support favicons. This gave IE a small but visible competitive advantage—websites looked more polished and branded in IE than in Netscape.
By 2000, website owners started creating favicons in significant numbers. The concept had proven itself useful beyond Microsoft's original analytics purpose. Users actually liked seeing custom icons in their bookmark lists.
The Link Tag Revolution
The original favicon implementation had a significant limitation: the icon had to be named favicon.ico and had to live in the root directory. What if you wanted a different filename? What if you ran multiple sites on subfolders of a single domain?
The solution came with the introduction of the <link> tag approach:
<link rel="icon" href="/images/my-custom-icon.ico">
This was a game-changer. Now favicons could be named anything, stored anywhere, and different pages on the same site could have different favicons. The rel="icon" syntax became the foundation for all future favicon implementations.
Internet Explorer, characteristically, went its own way with rel="shortcut icon" (two words). This wasn't officially part of any specification, but IE required it for years. The workaround most developers adopted was to include both:
<link rel="shortcut icon" href="/favicon.ico">
<link rel="icon" href="/favicon.ico">
You'll still see this pattern in legacy code today, though modern IE and Edge no longer require the "shortcut" keyword.
Firefox and the PNG Revolution (2004-2006)
When Mozilla Firefox launched in November 2004, it brought a crucial innovation: support for PNG favicons. This was enormous for designers.
ICO files were created using specialized tools—you couldn't just export one from Photoshop. PNG, on the other hand, was a standard web format that every graphics application supported. Suddenly, creating a favicon was as simple as saving a 16x16 PNG file.
Firefox also displayed favicons in the address bar (the "location bar" in Mozilla terminology), not just in bookmarks and tabs. This increased the favicon's visibility significantly and made it a more important branding element.
The Animated GIF Experiment
Firefox also briefly supported animated GIF favicons. Some websites created blinking, spinning, or otherwise animated icons. The effect was usually more annoying than impressive—imagine 20 browser tabs all with animated icons competing for your attention.
Browser vendors quickly recognized this as a usability nightmare. While Firefox never removed GIF support entirely, the practice fell out of favor and most browsers today either don't support animated favicons or severely restrict their behavior.
Interestingly, there's been a recent resurgence of interest in animated favicons using JavaScript to swap PNG frames, but that's a different technical approach than native GIF animation.
Safari and the Touch Icon Era (2007-2008)
The iPhone launched in June 2007 and changed everything about how we think about web icons.
Apple faced a unique challenge: iPhone users could save websites to their home screen, where they'd appear alongside native apps. A 16x16 favicon would look terrible scaled up to sit next to app icons. Apple needed something bigger.
Their solution was the Apple Touch Icon—a separate icon system specifically for iOS. The first implementation required a 57x57 pixel PNG file named apple-touch-icon.png. Later versions added support for a <link> tag:
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
This marked the beginning of favicon fragmentation. Web developers could no longer create a single icon file—they now needed to consider multiple icon types for different contexts.
The Precomposed Controversy
Early iOS versions applied visual effects to Touch Icons automatically: rounded corners, a glossy shine, and a drop shadow. This made web shortcuts look more "app-like" but also meant Apple was modifying your brand's icon without permission.
Apple introduced apple-touch-icon-precomposed to let developers opt out of these effects:
<link rel="apple-touch-icon-precomposed" href="/apple-touch-icon.png">
Eventually, Apple removed the automatic effects entirely (starting with iOS 7's flat design in 2013), making the "precomposed" variant unnecessary. But you'll still encounter it in older tutorials and legacy code.
The Mobile Explosion and Size Proliferation (2010-2014)
The early 2010s brought an explosion of devices with different screen densities and home screen icon sizes. What started as a simple 16x16 icon became a complex matrix of requirements.
Android Joins the Party
Android didn't initially have a standardized web icon system like Apple's Touch Icons. Different Android browsers handled favicons differently, and adding websites to home screens was inconsistent.
Google Chrome for Android eventually adopted support for Apple Touch Icons as a pragmatic solution—so many websites already had them that supporting the existing standard made more sense than creating a new one.
Later, Android introduced its own icon preferences through the Web App Manifest (which we'll get to shortly), but Apple Touch Icons remain the fallback that most Android browsers use.
Windows 8 Tiles
Microsoft's Windows 8 (2012) introduced live tiles on the Start Screen, and with them, a whole new icon system for websites: msapplication-TileImage and msapplication-TileColor.
<meta name="msapplication-TileImage" content="/ms-icon-144x144.png">
<meta name="msapplication-TileColor" content="#ffffff">
Windows tiles used different sizes than Apple Touch Icons (144x144 primarily), further fragmenting the favicon landscape. Microsoft also introduced browserconfig.xml, an XML file that could specify multiple tile sizes and configurations.
This era represented peak favicon complexity. A thorough implementation might require:
- favicon.ico (16x16 and 32x32)
- Multiple PNG sizes for various browsers
- Apple Touch Icons at 57x57, 72x72, 114x114, and 144x144
- Windows tile images at 70x70, 150x150, and 310x310
Many developers threw up their hands and just provided a 32x32 favicon, accepting that their sites would look less polished in certain contexts.
The Web App Manifest Era (2015-Present)
The W3C's Web App Manifest specification, which gained traction around 2015, represented a systematic solution to favicon chaos. Instead of scattered <link> tags, a single JSON file could define all of a site's icons:
{
"name": "My Website",
"icons": [
{
"src": "/icon-192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "/icon-512.png",
"sizes": "512x512",
"type": "image/png"
}
]
}
Referenced from HTML:
<link rel="manifest" href="/manifest.json">
The manifest approach had several advantages:
- All icon definitions in one place
- Support for specifying image type and purpose
- Integration with Progressive Web App features
- A clear upgrade path as new requirements emerged
Chrome, Firefox, Edge, and Samsung Internet all adopted manifest support. Safari was slower to the party (as often happens with Apple and web standards) but eventually added support as well.
The Maskable Icon Innovation
One of the cleverest manifest additions was the "maskable" icon purpose. Different platforms crop icons differently—Android applies a circular mask, iOS rounds the corners, Windows uses squares. A single icon design can't look optimal everywhere.
Maskable icons solve this by defining a "safe zone" in the center of the icon (approximately 80% of the total area). Designers place critical elements in this safe zone, knowing the outer edges may be cropped differently on different platforms.
{
"src": "/icon-512-maskable.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "maskable"
}
This was the first time a favicon specification actually acknowledged and addressed the multi-platform display problem rather than just adding more sizes to the pile.
SVG Favicons: The Modern Frontier (2020-Present)
The most significant recent development in favicon history is SVG support. Chrome added it in version 80 (February 2020), Firefox had supported it even earlier, and Edge followed Chrome's lead.
SVG favicons offer compelling advantages:
- Infinite scalability—one file works at any size
- Smaller file sizes in many cases
- CSS media query support for dark mode adaptation
- Potential for simple animations
The implementation is straightforward:
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
The dark mode capability is particularly elegant. An SVG favicon can contain CSS that responds to the user's color scheme preference:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
<style>
circle { fill: #000000; }
@media (prefers-color-scheme: dark) {
circle { fill: #ffffff; }
}
</style>
<circle cx="50" cy="50" r="40"/>
</svg>
The main limitation is Safari, which as of 2024 still doesn't support SVG favicons. This means developers need to provide PNG or ICO fallbacks, somewhat undermining the "one file to rule them all" promise. Still, SVG support represents a major step forward in favicon capability.
Where Favicons Are Heading Next
Several trends are shaping the future of favicons:
Increased PWA Integration
As Progressive Web Apps become more capable, the line between websites and native apps continues to blur. Favicon systems will likely become more sophisticated, with better support for adaptive icons, app shortcuts, and richer installation experiences.
Potential Safari SVG Support
Apple's Safari team has been slowly adopting web standards that Chrome implemented years earlier. SVG favicon support feels inevitable, though predicting Apple's timeline is notoriously difficult. When it happens, SVG could become the single recommended favicon format.
Dark Mode as Standard
With dark mode now standard across all major operating systems, adaptive favicons are becoming expected rather than exceptional. Future favicon specifications may include more robust theming capabilities.
Simplification Efforts
The current state—where a comprehensive favicon implementation requires multiple formats, sizes, and platform-specific files—is widely recognized as too complex. There's ongoing discussion in web standards communities about simplifying requirements without sacrificing functionality.
What This History Means for You Today
Understanding favicon history explains the seemingly arbitrary requirements you encounter:
- Why ICO still exists: It's the 1999 original, and backward compatibility dies hard
- Why Apple Touch Icons are separate: Apple needed bigger icons for iOS before web standards caught up
- Why manifest.json matters: It's the systematic solution to years of ad-hoc additions
- Why you need multiple sizes: Different platforms evolved different requirements independently
The practical takeaway? A modern favicon implementation should include:
- An SVG favicon for modern browsers (with PNG fallback)
- An ICO file for legacy support
- Apple Touch Icons for iOS
- A Web App Manifest for PWAs and Android
If creating all these variations sounds tedious, that's because it is. This is exactly why favicon generators exist—they handle the format conversion, size generation, and cross-platform requirements automatically. Try generating some favicon ideas and you'll get all the files you need without wrestling with the historical baggage yourself.
Frequently Asked Questions
Why is it called a "favicon"?
The name is a portmanteau of "favorites icon"—referring to Internet Explorer's Favorites menu (their term for bookmarks). The name stuck even though favicons now appear in many more places than just bookmarks.
When did favicons start appearing in browser tabs?
Firefox popularized tab favicons in 2004-2005 as tabbed browsing became widespread. Before tabs, favicons were primarily visible in bookmark lists and the address bar.
Do all browsers support favicons now?
Yes, every modern browser supports favicons in some form. The differences are in which formats they support (Safari doesn't support SVG favicons) and how they handle platform-specific icons like Apple Touch Icons.
What was the first website to use a favicon?
This is difficult to verify, but Microsoft's own websites were among the first to implement favicons in early 1999. The Internet Archive's Wayback Machine shows favicon.ico files appearing on major websites throughout 1999 and 2000.
Will ICO format ever go away?
Probably not entirely. ICO support costs browsers almost nothing to maintain, and removing it would break the tiny icons on countless legacy websites. It's likely to remain as a fallback option indefinitely, even if best practices move toward SVG and PNG.