We Need a Favicon Standard

In the beginning favicons were very simple, 16 pixels square and done. The idea was for each website to have its own unique icon. So when people visited or bookmarked a website, it was easier to identify in the browser.

It was simple: one site = one favicon = one link in the markup.

Developers back then had it so easy. To add a favicon to any site, they could just include a link:

<link rel="shortcut icon" type="image/x-icon" href="/favicon.ico">

Ta-daaa. And life was good.

Thanks Change

But the Web kept on a changin’, technology — screens — continued to improve. Greater screen resolution and so all the images started getting larger and larger. Soon there were multiple-size favicons. It was common for favicon-generator sites to cover 16px, 32px, 48px, 64px, 128px, and even larger sizes. So your site could display any size icon, or even get fancy and include multiple favicon sizes all in the same file.

Then apps came along and said, your website is special to us. You can create a custom favicon, link it in such a way, and it will be displayed on our great app. For example, iOS Safari introduced its own proprietary set of favicons, included like this in the markup:

<link rel="apple-touch-icon" href="touch-icon-iphone.png">
<link rel="apple-touch-icon" sizes="76x76" href="touch-icon-ipad.png">
<link rel="apple-touch-icon" sizes="120x120" href="touch-icon-iphone-retina.png">
<link rel="apple-touch-icon" sizes="152x152" href="touch-icon-ipad-retina.png">

So now developers wanting to cover all bases, have to include regular icons plus all the Apple specific icons. Then other apps wanted in on the hot proprietary action. So devices and apps like Google (Android), Microsoft (Internet Exploder), and Apple (Safari), all had their own special way of formatting and including icons in web pages. So adding a favicon to a website was no longer as simple as this:

<link rel="shortcut icon" type="image/png" href="/favicon.png">

It somehow got to the point where a ridiculous amount of time and work were required just to figure out the current favicon configuration, requirements, markup. Eventually, adding a favicon to your site got as ridiculous as this:

<link rel="apple-touch-icon" sizes="57x57" href="/images/icons/apple-touch-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="/images/icons/apple-touch-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="/images/icons/apple-touch-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/images/icons/apple-touch-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="/images/icons/apple-touch-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="/images/icons/apple-touch-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="/images/icons/apple-touch-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="/images/icons/apple-touch-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/images/icons/apple-touch-icon-180x180.png">
<link rel="icon" type="image/png" href="/images/icons/favicon-32x32.png" sizes="32x32">
<link rel="icon" type="image/png" href="/images/icons/android-chrome-192x192.png" sizes="192x192">
<link rel="icon" type="image/png" href="/images/icons/favicon-16x16.png" sizes="16x16">
<link rel="manifest" href="/images/icons/manifest.json">
<link rel="mask-icon" href="/images/icons/safari-pinned-tab.svg" color="#21759b">
<link rel="shortcut icon" href="/images/icons/favicon.ico">
<meta name="msapplication-TileColor" content="#2b5797">
<meta name="msapplication-TileImage" content="/images/icons/mstile-144x144.png">
<meta name="msapplication-config" content="/images/icons/browserconfig.xml">
<meta name="theme-color" content="#ffffff">

For a favicon.

This is favicons without standards. The amount of markup and number of files required to add favicons properly fluctuates from year to year. Currently it’s not as crazy as it was a few years ago (as in the above code example), but it’s still a real mess and headache to boot. Why should billions of web pages have to add all the redundant markup and megabytes worth of extra images just to share a favicon?

We need a single, unified Favicon Standard.

Think Future

If you inspect the above mess of spaghetti favicon code, you’ll find everything from ICOs to PNGs to SVGs. And as if all the different sizes and formats weren’t enough, there’s even some JSON and XML thrown into the mix, just to make everything as complicated as possible. Every client defining its own arbitrary favicon terms is absurdity. It’s like a scaled-down version of the 90’s browser wars, all over again.

And every time some new service or app comes out, they add another set of their own proprietary favicon images. So billions of web pages need to be updated to cover all the latest favicon formats and rules. Then Apple or Microsoft decides to change their favicon requirements (again). Do all those billions of pages automatically get updated to account for the new changes? No, they don’t. Again it’s up to developers to do the work. Ultimately and needlessly wasting time, resources and energy. Constantly changing, year after year after year. This is not a scalable solution.

Imagine another 10 years, there may be hundreds of icons. Developers will need to include myriad resources, images and code to account for all the browsers, apps and operating systems. Staying on this track, we would be wise to invest in some good favicon generator services. Instead, let’s set up a unified standard for favicons that’s simple and easy for anyone to use.

Some Math

To put things into perspective, let’s look at some math.

Say there are a billion websites comprising a trillion individual web pages. Each web page adding around five kilobytes of extra markup to include all the different favicon formats and proprietary variations. Then multiply each page by some average number of visits happening every day. Without actually crunching the numbers (someone check my non-math here), you’re talking upwards of around 5,000 terabytes worth of needless markup wasting precious server resources and bandwidth every day.

And that’s just the markup. The extra image sizes, retina and high-definition and whatnot — all the extra favicon data required just to share a site’s chosen icon. Talking thousands if not hundreds of thousands of petabytes worth of redundant favicon image data. Every day. For favicons.

Beyond saving massive resources and energy, a favicon standard would save tons of time and work. Think about it. Say there are 10,000 apps out there that make use of favicons. Now compare that to the number of websites, which is in the billions.

10,000 browsers/apps < Billions of websites

So where is the onus here? On the billions of websites that just want to share a favicon, or on the relative handful of apps (e.g., browsers) that make use of them? Which provides the greatest benefit?

Get Standard

Imagine being able to add a favicon to your website with something like this:

<link rel="favicon" href="/favicons/">

One line of code pointing to the site’s favicon directory. Contained in the directory would be whichever sizes and formats named according to standard. For example inside of /favicons/ folder the following images:

favicon-32.png
favicon-64.png
favicon-128.png
.
.
.

No need for “one-size-fits-all” thinking here. The goal is simplification and flexibility. For example, if Apple or Microsoft or Android or whoever requires some special formats or sizes, it can be communicated via the file name:

favicon-apple-ios-256.png
favicon-android-transparent.png
favicon-microsoft-edge-256x128.png
.
.
.

And so forth. The browser could make use of whichever icon they needed with a simple request. If the necessary file does not exist, use a fallback:

favicon-apple-ios-256.png
favicon-android-transparent.png
favicon-microsoft-edge-256x128.png
.
.
.
favicon-default.png

This is just one idea, there are many possible ways to go about it. You could even skip the link markup entirely and just add a favicon.txt file to your site. The file could contain the URL to favicon directory, specific rules, or whatever works best.

Simpler = Better

Having a simple yet flexible Favicon Standard would mean:

• Web developers — add favicons with one line of code or text file
• Browser/app vendors — make use of favicons however is necessary

The onus should be on browsers/apps, not on website developers. There should be an easy-to-follow specification for everyone. Just like it is with HTML and CSS. Instead of requiring a random mess of redundant and confusing markup, make adding a favicon as simple and easy as possible for everyone.

About the Author

Jeff Starr = Fullstack Developer. Book Author. Teacher. Human Being.