Celebrating 20 years online :)
Web Dev + WordPress + Security

We Need a Favicon Standard

Generic Favicon 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.

Update: Thanks to Manuel Strehl for putting together a draft proposal for a favicon standard, which you can read here.

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.

Use a Generator! All that code above? Yeah I didn’t write that, I used a free online favicon generator. Just upload your image, click a button, and a generator will generate all the necessary code and files for you. The only problem is, you’ll get significantly different results depending on which generator you use. Another reason why we need a 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:


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:


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:


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 = Web Developer. Security Specialist. WordPress Buff.
Digging Into WordPress: Take your WordPress skills to the next level.

12 responses to “We Need a Favicon Standard”

  1. I love your favicon directory idea Jeff. I hope browser and app developers will pick up on something like this. It would indeed make our lives so much easier.

  2. Instead of individual icons, I’d also find it useful if a single SVG was sufficient to handle all sizes. SVGs scale easily and are now, thankfully, also supported by most browsers as favicon. The support just doesn’t go far enough yet.

    • Jeff Starr 2021/03/28 11:27 pm Reply

      Absolutely, SVG is an excellent format for favicons. No reason to limit to just raster formats like JPG and PNG.

  3. Sounds great. Now make it happen 😀 so.

  4. Support for svg favicons have been added to chrome and firefox along time ago! See here: https://www.chromestatus.com/feature/5180316371124224

  5. You should research the manifest file spec. because you can delete all those favicons links you have listed in this article and place all your icons in a single manifest file. Therefore you would end up with a single link to the manifest file. That’s one of the reasons why the manifest file was created in the first place!

    • Jeff Starr 2021/04/19 8:27 am Reply

      Thanks bob, I had forgotten about the manifest file. There remains the issue that you need a million different sized icons and formats to satisfy the myriad browser/client requirements.

  6. Universal favicon please!

  7. The single directory for favicons is actually a good proposal. It could also be included in /.well-known/ folder that contains all standardized files that were previously in the same page of problems as the favicon conundrum. ICO, PNG, GIF, XML, JSON, MANIFEST and whatnot.

    The other alternative is of course a programmatic favicon.php served as favicon.ico file that detects the browser and serves the appropriate file, although that has put a lot of unnecessary memory load and cache in our webserver in the past.

Leave a reply

Name and email required. Email kept private. Basic markup allowed. Please wrap any small/single-line code snippets with <code> tags. Wrap any long/multi-line snippets with <pre><code> tags. For more info, check out the Comment Policy and Privacy Policy.

Subscribe to comments on this post

Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
GA Pro: Add Google Analytics to WordPress like a pro.
Crazy that we’re almost halfway thru 2024.
I live right next door to the absolute loudest car in town. And the owner loves to drive it.
8G Firewall now out of beta testing, ready for use on production sites.
It's all about that ad revenue baby.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.