Mathias Bynens

rel="shortcut icon" considered harmful

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, 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 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.

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 a “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.)

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">

Update: 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.

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.

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 of eval can 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, 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.

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.

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, 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: 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 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 <link rel="shortcut icon" href="..." /> 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.

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.

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:

<link rel="icon" href="/favicon.svg" type="image/svg">
<link rel="shortcut" href="/favicon.ico" type="image/x-icon">

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).

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 .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:

<link rel="shortcut icon" href="/user1/CrazyCow.ico">

…and user #2 can specify:

<link rel="shortcut icon" href="/user2/FabulousTroubador.ico">

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:

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 <link> tags for specific favicons.

Mathias wrote on :

Nick:

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.

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.

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.

Leave a comment

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

Some Markdown is allowed; HTML isn’t. Keyboard shortcuts are available.

It’s possible to add emphasis to text:

_Emphasize_ some terms. Perhaps you’d rather use **strong emphasis** instead?

Select some text and press ⌘ + I on Mac or Ctrl + I on Windows to make it italic. For bold text, use ⌘ + B or Ctrl + B.

To create links:

Here’s an inline link to [Google](http://www.google.com/).

If the link itself is not descriptive enough to tell users where they’re going, you might want to create a link with a title attribute, which will show up on hover:

Here’s a [poorly-named link](http://www.google.com/ "Google").

Use backticks (`) to create an inline <code> span:

In HTML, the `p` element represents a paragraph.

Select some inline text and press ⌘ + K on Mac or Ctrl + K on Windows to make it a <code> span.

Indent four spaces to create an escaped <pre><code> block:

    printf("goodbye world!"); /* his suicide note
                                 was in C */

Alternatively, you could use triple backtick syntax:

```
printf("goodbye world!"); /* his suicide note
                             was in C */
```

Select a block of text (more than one line) and press ⌘ + K on Mac or Ctrl + K on Windows to make it a preformatted <code> block.

Quoting text can be done as follows:

> Lorem iPad dolor sit amet, consectetur Apple adipisicing elit,
> sed do eiusmod incididunt ut labore et dolore magna aliqua Shenzhen.
> Ut enim ad minim veniam, quis nostrud no multi-tasking ullamco laboris
> nisi ut aliquip iPad ex ea commodo consequat.

Select a block of text and press ⌘ + E on Mac or Ctrl + E on Windows to make it a <blockquote>.