Mathias Bynens

rel="shortcut icon" considered harmful

Published · tagged with HTML

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 link with the icon keyword, 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.ico against the document’s address, as if the page had declared that icon using the icon keyword.

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.

About me

Hi there! I’m Mathias. I work on Chrome at Google. HTML, CSS, JavaScript, Unicode, performance, and security get me excited. Follow me on Twitter, Bluesky, and GitHub.

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 of `eval` can be harmful?

wrote on :

[**Marcel:**](#comment-1) 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, `icon` is not an HTML4 `link` type either, but it is very much used/useful. `shortcut` is not harmful and is very useful in IE for a different scope than the URL bar graphics, see [the W3C home page](https://www.w3.org/). 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 `profile` attribute of the `HEAD` element. The `rel` attribute in `link` elements accepts multiple space-separated `link` types as specified by W3C.

Sander wrote on :

[**Diego**](#comment-3): `icon` is [defined in HTML5](https://html.spec.whatwg.org/multipage/links.html#linkTypes "HTML5 Working Draft: Section 4.12.3: Link types"), though. **Mathias:** [“Considered Harmful” Essays Considered Harmful](http://meyerweb.com/eric/comment/chech.html).

wrote on :

[**Diego:**](#comment-3) (To continue [our discussion on Twitter](https://twitter.com/diegoperini/status/12280107651)…) 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, `shortcut` can 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:**](#comment-4) I consider the _“Considered Harmful” Essays Considered Harmful_ essay to be harmful.

Diego Perini wrote on :

[**Mathias:**](#comment-5) 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 `shortcut` value for the `rel` attribute in HTML5 is `bookmark`. But I am sure `bookmark icon` will 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 `` passes validation, because there’s nothing wrong with using `rel` values 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 the `rel="shortcut icon"` format.

wrote on :

[**Michael:**](#comment-7) 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.

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: * use of different favicons on different part of a website or component of a webapp * use a diffrent icon format like one supporting animations or SVG wich provide better rendering when resized * use a favicon shared over several domains or sub-domains * having the favicon being supported on more browsers 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.ico` file at the root of the website to prevent the loading of any 404 web page if not found (same as for the `robots.txt` file).

wrote on :

[**Alexandre:**](#comment-12) In all those cases, you will indeed need to specify the icons in the HTML. However, if all you want is a single `.ico` file to be your favicon, it’s actually beneficial to not use HTML at all (as explained in the article). > having the favicon being supported on more browsers I’m not sure what you mean here. Other than SeaMonkey, all browsers that display favicons fetch `/favicon.ico` by 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? > By the way, I still highly recommend to always have a default `favicon.ico` file at the root of the website to prevent the loading of any 404 web page if not found (same as for the `robots.txt` file). Yeah, me too. This is also mentioned in the article. :)

Karl wrote on :

Putting a link to link to `/favicon.ico` is 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… http://example.org/user1/ http://example.org/user2/ 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:**](#comment-11) 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 `email` and `url` inputs. Yay, nice iOS keyboards for these inputs ^^

Alexandre Morgaut wrote on :

[**Mathias:**](#comment-13) > having the favicon being supported on more browsers 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×8 or 16×16, 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 create two `` tags for specific favicons.

wrote on :

[**Nick:**](#comment-16) > 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. 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 `link` tag.

wrote on :

[**Olivier:**](#comment-23) > […] there’s no need to use the `shortcut` keyword. Exactly, that’s what this post is about. > […]what puzzles me is the `sizes` attribute […] [The `sizes` attribute](https://html.spec.whatwg.org/multipage/links.html#attr-link-sizes) can be used to define the sizes of icons for visual media. [Touch icons](/notes/touch-icons) are the perfect use case.

Max Shomeah wrote on :

Btw, what if you add several link tags with both `icon` and `shortcut icon` set? 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](http://html5boilerplate.com/) doesn’t use the `` 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 named `favicon.ico` (**fav**orites 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.

wrote on :

[**Nick:**](#comment-27) I’m afraid that ship has sailed. As explained in this post, all browsers already request `/favicon.ico` by 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 `` is the choice per designer, and the same goes for the syntax. In most cases invalid anyway. `image/x-icon` is 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.

wrote on :

[**John:**](#comment-30) IE ≤ 10 as well as most mobile browsers would ignore it — see [my write-up on touch icons](/notes/touch-icons) for details. Either way, you’d still need a `/favicon.ico` file 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 `` tags for specific favicons.

Antônio Vinícius wrote on :

Am I wrong, or according to [RealFaviconGenerator Compatibility](http://realfavicongenerator.net/favicon_compatibility) there’s no difference between putting pictures in the root directory and putting pictures into a subdirectory? The result tables look the same…

Leave a comment

Comment on “rel="shortcut icon" considered harmful”

Your input will be parsed as Markdown.