Most sites use the following HTML to specify a favicon:
<link rel="shortcut icon" href="/favicon.ico">Looks okay, right? Guess what — it isn’t!
Today, I learned that shortcut is not a valid link relation. Indeed, it doesn’t show up in section 4.12.5 of the HTML5 specification on ‘link types’. It is, in fact, proprietary to Internet Explorer. Without IE, rel="icon" would suffice to specify a favicon.
So, do we have to use the shortcut relation to support IE? Not at all.
If the shortcut value is omitted from the rel attribute, Internet Explorer ≤ 8 ignores the declaration entirely, searches for a file called favicon.ico in the site root, and uses that instead. In fact, almost every browser does that when there’s no link rel="icon" specified. Using rel="icon shortcut" won’t work in IE either, since it doesn’t treat the rel attribute as a space-separated list.
Update: If the Release Candidate is any indication, IE9 won’t doesn’t require the shortcut link relation anymore if you specify type="image/x-icon". Needless to say, this still sucks — all the more reason to just name the icon favicon.ico and place it in the root of your domain.
Just make sure to always put the favicon in the root directory of your site, and name it favicon.ico. This way, Internet Explorer will detect it, regardless of whether you’re specifying it in a link element or not. And if you omit the entire link rel="icon" declaration, other browsers will go looking for that file as well. Not having a favicon.ico file in your root will cause a lot of 404 errors.
Almost all modern browsers look up /favicon.ico by default: Opera, Safari, Chrome, Firefox, Internet Explorer 5+. The only browser that currently doesn’t do this is SeaMonkey.
(SeaMonkey does offer an “aggressively look for website icons when the page does not define one” setting, though, but it’s disabled by default. Firefox does it the other way around: it has a browser.chrome.favicons entry in about:config which can be set to false to disable this behavior, but the default value is true.)
Note that this works even for icons that are not in the ICO format! Browsers that support SVG favicons look for /favicon.ico all the same, and nothing stops you from serving an SVG resource with Content-Type: image/svg+xml at that URL. It’s just a URL. File extensions don’t really matter on the web.
This means you can omit the link declaration for the favicon from your HTML entirely, if you want. The only real difference is that the favicon will only be shown once the entire document has finished loading. In comparison: if you’re specifying it explicitly, the favicon is loaded as soon as the browsers parses the link rel="icon" declaration. I’d say this is a huge plus. It’s definitely worth it to defer loading the favicon so that the browser can focus on loading the document and all other assets first.
If you want your favicon to load as soon as possible and/or if you insist on displaying it in SeaMonkey, you can simply use this code:
<link rel="icon" href="/favicon.ico">Another update: The HTML spec now explicitly mentions /favicon.ico:
In the absence of a
linkwith theiconkeyword, for documents obtained over HTTP or HTTPS, user agents may instead attempt to fetch and use an icon with the absolute URL obtained by resolving the URL/favicon.icoagainst the document’s address, as if the page had declared that icon using theiconkeyword.
Update: For historical reasons, the HTML specification now allows the use of shortcut as a link relation if it’s immediately followed by a single U+0020 space character and the icon keyword. Of course, it’s still better not to use any HTML at all.
Update: Internet Explorer 11 will support GIF or PNG favicons, not just .ico files. Yet still, /favicon.ico remains the implied default.
Thanks to Anne and Sander from the #whatwg IRC channel for taking the time to explain this to me.
Comments
Marcel wrote on :
Ok, nice to know. But isn't the title a little bit exaggerated? What do you mean by considering
rel="shortcut icon"harmful? Harmful in the sense that an inproper use ofevalcan be harmful?Mathias wrote on :
Marcel: The title might be a bit exaggerated — using
rel="shortcut icon"doesn’t really do any harm, but then again most of the time it doesn’t do any good either. Oh well, I just needed something that sounds good :)Diego Perini wrote on :
Mathias,
iconis not an HTML4linktype either, but it is very much used/useful.shortcutis not harmful and is very useful in IE for a different scope than the URL bar graphics, see the W3C home page.I don’t want all my pages have the same favorite icon and I believe others may have the same requirements.
If needed one can define new link types using the
profileattribute of theHEADelement. Therelattribute inlinkelements accepts multiple space-separatedlinktypes as specified by W3C.Sander wrote on :
Diego:
iconis defined in HTML5, though.Mathias: “Considered Harmful” Essays Considered Harmful.
Mathias wrote on :
Diego: (To continue our discussion on Twitter…) Sure, if you want to use more than one favicon on the same domain, and get that working properly in IE, you’ll have to stick with
rel="shortcut".My point is that for most sites, this isn’t the case — and in these cases,
shortcutcan and should be omitted IMHO. I understand it’s still a necessity in cases where you really need distinct icons per document, but most of the time it’s not really needed.Sander: I consider the “Considered Harmful” Essays Considered Harmful essay to be harmful.
Diego Perini wrote on :
Mathias: I understand that for most sites this isn’t the case, but for the rest it is. Though understand that for sites having only one same ‘root’ directory for several different sites this will not allow for different ‘icons’ for each of the sites hosted there. All my clients sites share the same ‘root’ directory thus the same root favicon. I am not saying IE method to do it is the correct one, however I need to follow how these browsers work to make the ‘thing’ equally usable to all visiting browsers.
The equivalent
shortcutvalue for therelattribute in HTML5 isbookmark. But I am surebookmark iconwill not work in any browser. So we need IE to catch up and allow for full path to icon resources, as all other browsers already understand that.Michael wrote on :
I realize I’m a bit late to the party, but I just want to point out that
<link rel="shortcut icon" href="..." />passes validation, because there’s nothing wrong with usingrelvalues that aren’t on the W3C’s list. In fact, if you look at the source code for w3.org, you’ll see that even they use therel="shortcut icon"format.Mathias wrote on :
Michael: Just because the validator allows it doesn’t mean it’s a good idea.
The take-away is: just name your favicon
favicon.ico, place it in the root of your site, and there’s no need to put anything in the HTML — especially no proprietary link relations.Mathias wrote on :
I’ve added a small note to the article now that the HTML5^H spec explicitly mentions
/favicon.ico.Russell Bishop wrote on :
I’d suspected that this was true, but never took the time to test the theory. Thanks for the info Mathias!
Ilia wrote on :
The one problem with not using the link tag for a favicon is that you are limited to the default favicon name and the ICO format, if for whatever reason you wanted to use a GIF or a PNG, or just change the name of the file you'll need the explicit specification. Of course you could argue that we shouldn't be using a GIF or a PNG for a favicon in the first place, but I just wanted to point this out.
Alexandre Morgaut wrote on :
Some cases where this tag can be useful:
I prefer to have two link element to avoid compatibility issues, allowing to use the best supported format on different browsers:
By the way, I still highly recommend to always have a default
favicon.icofile at the root of the website to prevent the loading of any 404 web page if not found (same as for therobots.txtfile).Mathias wrote on :
Alexandre: In all those cases, you will indeed need to specify the icons in the HTML. However, if all you want is a single
.icofile to be your favicon, it’s actually beneficial to not use HTML at all (as explained in the article).I’m not sure what you mean here. Other than SeaMonkey, all browsers that display favicons fetch
/favicon.icoby default (and chances are SeaMonkey will do this too now that the spec explicitly mentions it). The ICO format is supported by every browser that actually uses it (e.g. Mobile Safari doesn’t use favicons at all so it doesn’t really matter if they support it or not). Were you talking about supporting SeaMonkey, or something else? Could you be more specific?Yeah, me too. This is also mentioned in the article. :)
maht wrote on :
Why on earth is the HTML spec having anything to do with
favicon.ico, that’s insidious mission creep!Karl wrote on :
Putting a link to link to
/favicon.icois indead pointless, but that is missing the point of link and the WKL issue, aka squatting the name space. Now imagines that there are users sharing a common domain such as…There is a practical usage for link to authorize each users to have its own icon. User #1 can specify:
…and user #2 can specify:
Nick Sergeant wrote on :
Ilia: You can actually have a GIF or PNG be the actual file format and still have a name of
favicon.ico. We do it all the time.MyFreeWeb wrote on :
How about putting a
link rel="shortcut"in a conditional comment? That’s extra bytes, but that would be very right. Some IEFML (IE Fucked Markup Language) embedded in a HTML comment.P.S. Your blog is the first blog I’m commenting on that has
emailandurlinputs. Yay, nice iOS keyboards for these inputs ^^Alexandre Morgaut wrote on :
Mathias:
Two precisions about this use case:
<link>tags for specific favicons.Mathias wrote on :
Nick:
Sure you can, but the icon won’t show up in IE then.
Philip Tellis wrote on :
Isn’t it also important to have your favicon on a cookie-less domain? In many cases, the size of cookies could actually be larger than the favicon itself.
Phil Smith wrote on :
Looking at the 3 biggest on the Internet {Apple, Google, and Microsoft} shows that the root directory is where they place and name the icon and that "NO CODE" is needed to add to the webpages.
Michael Mahemoff wrote on :
One exception is dynamic favicons, which have many valid uses, e.g. to get the user’s attention or show status info. Dynamically updating favicon requires changing the
linktag.Olivier Allais wrote on :
According to https://html.spec.whatwg.org/multipage/links.html#rel-icon there’s no need to use the
shortcutkeyword. But what puzzles me is thesizesattribute?Mathias wrote on :
Olivier:
Exactly, that’s what this post is about.
The
sizesattribute can be used to define the sizes of icons for visual media. Touch icons are the perfect use case.Max Shomeah wrote on :
Btw, what if you add several link tags with both
iconandshortcut iconset? This can be useful if you want your icon be placed at static files storage, like CDN instead of site root.Rajeesh wrote on :
I was wondering why HTML5 Boilerplate doesn’t use the
<link>tag for the favicon. Thanks for the info! :)Nick Moline wrote on :
As has been stated here, just relying on
favicon.ico’s existence seems poor advice. It requires browsers to make a blink request to an arbitrary URL after the page is loaded with no reason other than because some engineer at Microsoft in 1999 decided to write support for looking for a file namedfavicon.ico(favorites icon, when no other browser other than IE calls them favorites) is ludicrous. We should be convincing web developers to move TOWARDS specifying the shortcut icon in hopes that browsers can eventually stop doing a wasted URL grab for a URL that may or may not (in practicality probably not) be there.Mathias wrote on :
Nick: I’m afraid that ship has sailed. As explained in this post, all browsers already request
/favicon.icoby default, and no amount of developer advocacy and evangelism will change that.phc wrote on :
Well, I may be late for the cake, but I still enjoyed scrolling down the years. Whether to use
<link rel>is the choice per designer, and the same goes for the syntax. In most cases invalid anyway.image/x-iconis an invention by the friendly folks from Redmond. I played around with the proper MIME and was fascinated to learn how poor support for the valid spelling actually is. One is almost forced to break his/her code to maintain compatibility. Anyway, I’ll stick to adding the extra (invalid) mark-up to define whatever I or my clients want to use as icon. Technically it would be perfectly possible to even link a video; albeit it might seem a little small…John Hughes wrote on :
If you were only interested in the latest browsers, could you just use a single, really high resolution PNG and ignore everything else? The file would still be pretty small and will get scaled down fine by whatever browser you are using.
Which current browsers would ignore this? It even seems to work with IE11 and it would save a lot of time and effort.
Mathias wrote on :
John: IE ≤ 10 as well as most mobile browsers would ignore it — see my write-up on touch icons for details. Either way, you’d still need a
/favicon.icofile to avoid 404s in your server logs.trlkly wrote on :
If you’re going to say something is harmful, you need to actually somehow prove it is harmful. You admit in your second comment that this is not actually harmful. I don’t think it’s right to lie in your titles.
Tech Leaks wrote on :
Two precisions about this use case:
First, I’m an old web developer ;) and I had to face Firefox versions which didn’t support the ICO format. Also note that the ICO format can be more or less supported and some browsers may expect specific sizes to be present in the ICO file (8×8px or 16×16px, I don’t remember). The ICO format is not as rich as some others, so if you want to take advantage of the SVG format, you will still have to provide an ICO version for IE. This is one of the reasons why I’m used to creating two
<link>tags for specific favicons.Antônio Vinícius wrote on :
Am I wrong, or according to RealFaviconGenerator Compatibility there’s no difference between putting pictures in the root directory and putting pictures into a subdirectory? The result tables look the same…