Dear Web browser developers,
Please stop automatically requesting /favicon.ico from our servers. It's annoying. Some of us don't want a favicon. Some of us haven't yet made a good one. Some of us have large 404 error pages that have to be sent if we don't comply with your "standard". Many of us have good reasons, but we all hate seeing constant 404s in our logs for /favicon.ico.
First, a brief history of the favicon: In March of 1999, Internet Explorer 5 was released. It was the first browser to support favicons. At that time, they were a proprietary feature and not a part of any specification. The browser would attempt to download the file /favicon.ico from any website that was added to the user's bookmarks[1]. This image was then displayed next to the bookmarked URL in the address bar.
Interestingly, this behavior was used by webmasters of the time to estimate how many of their visitors bookmarked a page on their site. This alternative use was short lived, however, because most browsers would start to download the favicon and display it for any website visited, regardless of bookmarks.
Shortly after the favicon was introduced to the world, it was officially recognized by the World Wide Web Consortium in the HTML 4.01 recommendation. To define a favicon, you would use a link tag, similar to the following. You were allowed to use any image format you wanted, not just Microsoft's .ico format.
<link rel="icon" type="image/png" href="http://example.com/icon.png">
The adoption of HTML 4.01 should have caused the automatic fetching of /favicon.ico to become deprecated in all browsers. The recommendation came out less than a year after Internet Explorer 5, so nothing of value would have been lost. Webmasters would have updated their pages to include a link to a favicon, or suffer the very minor consequence of not having a little picture next to their website's name when they loaded it in their favorite browser.
Unfortunately, most of the popular browsers at the time left that "feature" included, and even now in the year of our lord 2021 2023 it is still a part of all major browsers by default.
The HTML "Living Standard" from WHATWG currently includes a mention of /favicon.ico, and it seems to have been there since 2011. I think it's safe to say that we are past the point of no return, at least in explicitly disallowing this behavior on a specification level.
That's not to say there haven't been attempts. Sir Tim Berners-Lee himself tried to stop this from happening with the proposal of a new standard called "SiteMetadata". Webmasters would create a dedicated file in a location of their choosing that pointed to icons as well as other resources like privacy policies, robot control files, site maps, you name it. He explained his reasoning for the proposal very well. From his post to the W3C Technical Architecture Group mailing list on February 10th, 2003:
The architecture of the web is that the space of identifiers
on an http web site is owned by the owner of the domain name.
The owner, "publisher", is free to allocate identifiers
and define how they are served.
Any variation from this breaks the web. The problem
is that there are some conventions for the identifies on websites,
that
/robots.txt is a file controlling robot access
/w3c/p3p is where you put a privacy policy
/favico is an icon representative of the web site
and who knows what others. There is of course no
list available of the assumptions different groups and manufacturers
have used.
These break the rule. If you put a file which happens to be
called robots.txt but has something else in, then weird things happen.
One might think that this is unlikely, now, but the situation could
get a lot worse. It is disturbing that a
precedent has been set and the number of these may increase.
You can read the rest of the proposal here, in the mailing list archive. It's interesting to think about the possibilities of a system like this.
As Berners-Lee explained, the Web was created in such a way that gave webmasters the freedom to decide where files should go and how identifiers should be handled. Conventions that define an explicit location for certain kinds of files undermine this freedom, and can cause problems for developers making Web services that do not have the ability to easily serve static files at a particular location.
A favicon is not a requirement for a valid website like a title is, but the automatic fetching of /favicon.ico makes it a sort of unofficial requirement. It forces those of us who don't want a favicon to use hacks like <link href="data:," rel="icon"> and put a dummy favicon.ico in our Web root. If we don't comply, our log files are hit with hundreds of 404 errors, both in our sever logs and in our visitors' consoles, that are not our fault nor the fault of our visitors.
No matter what the reasoning is, though, there is simply no reason for this archaic quirk to continue to exist. Backwards compatibility can be a great thing, but when a feature implemented for backwards compatibility involves forward frustration it's time to consider removing it. /favicon.ico had a good run, but it needs to be let go.
That is why we are calling upon you, the developers of our favorite Web browsers, to remove this anti-feature or at least leave it off by default.
Sincerely,
(a plurality of) Webmasters
The best solution would be for the Web browsers to stop this behavior. SeaMonkey is the only "modern" browser I know of that has it disabled by default. Users of Firefox and other derivatives can also disable it by toggling browser.chrome.site_icons to "false" in about:config.
That doesn't help much, though. Most people will be using Chrome or Firefox with default settings, so you need to be more creative to stop your logs from filling up with 404s. The method I use on this website was mentioned before: a <link> for a favicon pointing to a blank data URI.[2] This solves the problem on most modern browsers, it's just a little hacky.
<link href="data:," rel="icon">
Also mentioned before, you'll probably want to put a dummy favicon.ico in your Web root, if nothing else to make it easier to grep your logs for errors. I use a 198 byte, fully transparent icon that is, to my knowledge, the smallest a valid .ico file can get. It's less than half the size of my 404 error page, so at least it has that going for it.
Update 2023-05-08: Improve grammar and word choice throughout, explain things more thoroughly in the appendix.