Jekyll2026-08-05T05:11:43+00:00https://fiiv.io/feed.xmlNikita TimofiivWeb professional with 16 years of experience.Everything you’ve (n)ever wanted to know about favicons2021-10-27T00:00:00+00:002021-10-27T00:00:00+00:00https://fiiv.io/blog/everyting-youve-never-wanted-to-know-about-faviconsA favicon is quite simply an icon. The idea behind its inception was for browsers to use them to make a quick, easy to identify visual representation of a website in the browser’s UI.

Favicon as it appears in Firefox

A little bit of history

The first favicons were implemented in 1999 by Microsoft in their Internet Explorer browser. Since then, they were widely adopted by almost all browsers, and today it is commonplace to find favicons being displayed all over the browser, such as in bookmarks menus, window and tab headings, address bars, history, etc.

Microsoft’s original idea was to load that icon from a specific place relative to a website. If your website’s address was pokemon.com, Internet Explorer looked for it at pokemon.com/favicon.ico.

This original implementation worked alright at first. But at the time, lots of websites were hosted with companies like Geocities, Angelfire and Tripod. They would give your website an address like tripod.com/my-pokemon-website. The problem with this was that the browser would always use Tripod’s favicon located at tripod.com/favicon.ico and not one that the website’s author might want to show!

Eventually, the people responsible for standardising HTML on the web, the World Wide Web Consortium (W3C), created a specification for how both browsers and website authors should use these icons. In the HTML of the page, an HTML tag would be included, telling the browser where to find that icon.

But, since the original Internet Explorer needed to work because lots of websites had been using it, browsers began supporting them both.

The advent of the smartphone (and other use-cases)

A lot of things changed when the smartphone became mainstream. One notable thing that changed for favicons was that people could save websites to their home screen. But the favicon.ico icons up to this point were all too small – sometimes they were as tiny as 16 pixels! These icons were supposed to be shown next to app icons, which are much more high fidelity images – up to 10 times bigger, in fact!

Android and iOS use different icon sizes. Also, Windows began using yet another icon type for displaying websites in its Metro tile display.

The chaos is real

As a result of all these different specifications, there are now a lot of places to look for favicons. And the different icons you can get will vary depending on which one you request. Some sites will have some but not others!

The list includes:

  • yoursite.com/favicon.ico
  • In the site’s HTML code
  • In the site’s web manifest file

Some sites end up with dozens of different icons. These vary, from the usually tiny favicon.ico to the higher resolution icon used by iOS’s home screen feature. Additionally, a lot can go wrong with fetching these.

  • There might not be any icons at all.
  • The icons are specified but don’t exist (return a 404).
  • The icons are the wrong size.
  • The icons are the wrong format for where you might want to use them.
  • The icons are corrupted or broken.
  • The icons specified might not have the one you might want to use.
  • The web server could be misconfigured (for example, resulting in redirect loops).
  • The web server could be slow to respond with the icons or the files specifying the icons.

So, requesting something as simple as a tiny little website icon can be a very complicated task! Clearly there is no one-size-fits-all solution to grab the icons.

How to make sure your website has all its icons

So all that being said, how do you make sure your website has all the different icons it should have, and they’re properly referenced in your HTML markup?

Quite simply, the best way to do this is to use a service that generates the markup and icons for you. The best ones I’ve found so far are realfavicongenerator.net and Website Planet’s Favicon Generator. You can upload an icon image, specify some preferences, and it will generate a ZIP file with your icons properly sized and set up, as well as the HTML to insert into your site’s <head> section.

If you use Webpack, you could also try out the plugin jantimon/favicons-webpack-plugin that will automatically work its magic to give you favicons.

How to use other sites’ favicons on your site

  1. You could build your own API or serverless function to fetch a site’s favicons. But, I gotta tell you from experience, there’s a lot of edge cases and weirdness here.
  2. You could always load domain.com/favicon.ico, but be prepared for 404s.
  3. You could use an existing service. Shameless plug – I built Icon Horse for this purpose, you can use it free (or upgrade for additional features). Other services also exist, like Favicon Grabber. Some search engines like Google, Bing and DuckDuckGo also have APIs for this, but since they’re intended for internal use and are undocumented and unsupported, be prepared that they might not work like you want or they might stop working at any moment.

Other cool stuff

]]>How &amp; why I built a favicon fetching service2021-09-04T00:00:00+00:002021-09-04T00:00:00+00:00https://fiiv.io/blog/how-why-i-built-a-favicon-fetching-serviceA few days ago, I launched Icon Horse, which is a simple, free API to quickly get the favicon of any website. The launch itself went really well, and I had a lot of fun building it.

But inside the seemingly simple but glamorous life of favicons, there is a lot of complexity. I thought I’d share some of how it works with you all, and some of the hoops I had to hop to build Icon Horse.

What is a favicon, really?

The year was 1999. Britney Spears and Eminem were at the top of the charts, the world was introduced to Napster for the first time, and the “browser war” was heating up with Microsoft releasing Internet Explorer 5.

One of IE5’s new features was the favicon, or a small icon which was displayed in the “Favourites” menus/bars next to the title of the site someone bookmarked. Things were simple back then, and if the favicon existed, it would be loaded from the site’s root like so:

https://mysite.com/favicon.ico

Since then, a number of new circumstances have come up requiring new types of icons – one example is the advent of the smart phone, which allowed people to save a website shortcut on their home screen. But since favicons tended to be low resolution, a number of diverging standards came about and added these on both Android and iOS.

Now while technically a shortcut icon, they are usually lumped in with favicons in general internet terminology and also during the process to create them.

Today, there are three main places to look for icons:

  1. https://mysite.com/favicon.ico
  2. The HTML of the site in the <head>
  3. A separate Web App Manifest file which is specified in the <head>

So what’s the problem?

I’m currently working on a tool called Meeting Canary, from which a note-taking interface is displayed for a given calendar meeting. Many meetings have links to relevant places, such as video conferencing apps (especially since the COVID-19 situation has moved many people to remote work).

I decided it would be nice to render a small icon next to the links, as a way to tease the content to my users:

A meeting invite often has a link

After hunting for a good way to fetch icons for a given link, I found one that was a JSON API endpoint, but I wasn’t very satisfied with this solution – I did not want to complicate my life by using it, since I still needed to write code to figure out the best icon to display from the list I got back.

Also, I did not find a single service that provided fallbacks, or an icon that would be shown if the site is unreachable or if it had no icons at all.

After all, Gravatar does this very well for email addresses, and it was strange that no one had done this with favicons yet! So I got to work.

It was really simple to make, right?

When it comes to standards, the web is pure chaos. When building a product to fetch favicons, you should expect no mercy.

The web is a hive of scum and villainy

Some sites have no icons at all. Some sites have only a few of the icons from the spec. Some sites use strange sizes. Some sites don’t even bother to tell you the size (in pixels) of the icons.

Some sites have completely broken DNS or server issues (like infinite redirect loops). Some send confusing or broken headers. Some sites serve invalid HTML or JSON. Some sites have 404 Not Found errors on their icons. Some sites used weird caching schemes. Some don’t specify a MIME type or a file extension so you have to parse the actual image to know what you’re dealing with.

The list of difficulties goes on – for example one prominent clothing retailer’s icon is simply not loadable because they have a nasty bug in their site’s redirects and headers meaning you cannot simply redirect: 'follow' your way to the HTML page, but must chain one request after the other manually.

But I persevered through all those.

I knew there was going to be even more edge cases I hadn’t considered in the future, so it was very important to build in functionality for fallback images. I never wanted to serve a broken image or a timeout.

I also had to make some decisions. Since my service was making icons available to all who wanted them, there was no telling the different use cases they would be serving. So I made the assumption that the best icon to serve would be the most high fidelity image. Also, for some use cases (such as React Native), SVG format icons would not work out of the box, and needed something like react-native-svg to get them to load, so I stuck to raster formats only (for the first version at least, I plan to open up SVGs as well in the future via a query parameter).

And finally, pulling all this content is time intensive. Consider that to serve an icon, one needs to:

  1. Load https://asite.com’s HTML site
  2. Parse the HTML and do a query lookup to get relevant icons and the manifest file
  3. Load the manifest file and parse it
  4. Check for the existence of the https://asite.com/favicon.ico icon
  5. Merge all these icons together in a list and sort them based on a best to worst criteria, while also making sure the icons themselves are reachable (and don’t 404 Not Found)
  6. If all this fails, generate a JPEG file on the fly as a fallback
  7. Serve the icon to the user

So when dealing with a slow server, it’s possible that loading that icon could take quite a long time. To help with that, Icon Horse must cache the resulting list of icons and the resulting chosen icon.

I wanted to keep the functionality super simple, so when someone queried my API to get an icon:

https://icon.horse/icon/dev.to

I ended up with just the icon:

dev.to icon

Putting it all together

From the very beginning, I knew I wanted to use a serverless approach to this service. The landing page is built out of Next.js and the service itself sits in a lambda function hosted on Amazon.

After struggling a little bit with getting the environment set up (it had to have image processing capability as well as a few other things), I managed to get it working and running properly.

And there you have it. I launched on ProductHunt (among other places) and was surprised by the overwhelming positive reception – I got almost 200 upvotes and almost 1000 unique visitors. What surprised me the most is how a favicon fetcher service I thought would be niche and developer only was actually really well understood by all kinds of people.

I learned a lot about the weird world of favicons and solved my own need, but above all had a lot of fun doing it.

Thanks for reading.

]]>