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.
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.
If the Release Candidate is any indication, IE9 won’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
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
In the absence of a
iconkeyword, 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 the
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.