when did favicon get so needy?

Most of us probably end up working on favicon.ico as an afterthought, say, after you’ve finally shown the work to someone else and you see that the default icon is in use. Up to this point in the project you’ve likely considered this as work to do later.

For those who don’t know this already, this is the icon file which was displayed in Internet Explorer just to the left of the URL in the Location field. At one time it was only 16×16 pixels and enjoyed very little screen real estate, if you will. The file if present in your website’s root directory would be pulled by the browser. If you were an early website implementer like myself your discovery of the concept was when you were reading the website’s log files and kept seeing all the "404 - file not found" errors from newer browsers which now expected it. So you likely created one to clean up your log files and shrugged it off.

Platform Wars

Fast-forward to today and there are many popular browsers as well as platforms. Perhaps the biggest change has been the advent of touchscreen platforms that demand much larger buttons in which to invoke your shortcut. Bigger buttons means that our earlier one-size-fits-all approach no longer works; you can’t scale up a 16×16 icon graphic to the huge sizes required for a web TV platform.

Unfortunately, nobody came up with a consistent standard for this. What would have been nice would have been for everyone to populate a folder structure like this:


And done. In this perfect world these would be the only icons and tiles available for the sum total of all browsers, all platforms, all devices. Period. If an operating system or browser needed something different, if would be necessary for that system to read the closest available graphic and to then create something else from it as required. It should not be up to the website designer to create what is seemingly required today.

Microsoft Internet Explorer

Microsoft originally specified /favicon.ico to include one or more images. It could contain a 16×16, 32×32 and/or a 48×48 pixel version. Although the first size is good enough for the location field of the browser, if the end-user minimizes the browser then the 16×16 doesn’t seem big enough for the taskbar within Windows. Alternately, creating a shortcut to the website under some screen resolutions and settings requires an even bigger default icon, hence the three sizes.

Speaking of which, what format is a .ico file anyway? Even though Microsoft has a tool within Visual Studio to combine multiple files into an .ico file, you can actually get away with just renaming a .gif, .jpg or .png file to favicon.ico and it will work fine with most browsers.

Mobile Platforms

It sounds like these need .png icons, one or more Apple Touch Icons, Windows 8 tile icons and a /browserconfig.xml file.

Google TV

Google TV wants an icon that’s 96×96 pixels.

Android Chrome

Chrome wants an icon that’s 196×196 pixels.

Opera Coast

Coast wants an icon that’s 228×228 pixels.

Apple Touch Icon

The iPhone/iPad collection of devices want an icon which is between 57×57 to 180×180 in size. The newer the device or in the presence of a Retina-technology screen, the higher the resolution it will need.

The odd thing here is that non-Apple browsers and platforms sometimes use the Apple-named icons because they’re usually better resolution than the default one.

Microsoft Metro Interface on Windows 8 and 10

You’d think that the 150×150 tile graphic would need to have that resolution but Microsoft recommends 270×270 for this one. Er, what?

Web Apps

And now, just when you thought this couldn’t be any more complicated, /manifest.json might also be necessary and it serves a similar function as /browserconfig.xml.

Finding Some Sanity In All the Chaos

The current wisdom appears to involve providing two and only two files: a 16×16 pixel /favicon.ico and a 152×152 pixel /images/apple-touch-icon.png. You’d then reference the latter with a tag within your HTML. The .ico version can include multiple resolutions inside it—the more, the better.

As developers I think we should push back a little and to make platform designers accept this approach and to gracefully work if this is all that’s available.

timing is everything

I discovered something strange and bothersome today when I began a debugging session on a Node.js—based website I was working on.  My logs were clearly showing that my browser was pre-caching content from a site before I visited it.


As you can see from the console.log() content on the right and a new Safari session, the browser is already fetching content in realtime as I type in “http:” in the address field.  Note that I haven’t pressed Enter or clicked anything yet to initiate the download.  Also note that the indicated site that’s been matched in the URL isn’t the site I’m debugging.  The site whose log is on the right is served on a different port.  So the assumption here is that Safari on startup tries to make things seem faster by pre-caching content from what it thinks you’ll need later.

“…Safari on startup tries to make things seem faster by pre-caching content from what it thinks you’ll need later.”

I already had a sense of this on my iOS device since it’s painfully slow when you switch back to the Safari app and hope to quickly lookup something.  No joy.  The iOS Safari app seemingly takes forever because of this startup pre-caching phase, it really grinds its gears trying to reload content from all the tabs that were open before, creating an unresponsive experience for the user.

What does this mean to the software developer?  Normally, we expect to follow a link and then the browser does our bidding. We next expect to review the logs in realtime and watch the performance for a session.  In some workflows I might startup the browser, edit a page, save that page and then visit the link to review the work I’ve just done.  But here we see that the browser anticipated that I might re-visit the site and has begun caching the content in case I might then ask for it.  For this scenario it was my intention though to see what it looks like including my latest edits and that’s not necessarily what I’d be viewing—I could very well be seeing the site from before my edits because my browser was trying to provide a responsive experience for me.

Looking for a workaround within Safari’s preferences, there doesn’t immediately seem to be a feature to turn off pre-caching of content.  This thread however appears to be addressing the concern and the following preference setting may be toggled off.