You don’t need any HTML to add a favicon to your site | Hacker News Reader

You don’t need any HTML to add a favicon to your site

mathiasbynens.be

28 pointsmathias13 comments

Open articleView on HN

If you've ever checked the 404 logs on a site with no favicon you already know this.

Yeah. I always did it this way, didn't realise until fairly recently you could use <link/> tags.

Does anyone know of any other user agents that don't hit /favicon.ico regardless? Feed readers for example?

The article mentions SeaMonkey, currently the only browser that doesn’t fetch /favicon.ico by default.

But yeah — some web apps rely on /favicon.ico as well. All the more reason to just place it there :)

Downside: if you include it as an HTML link you can use a PNG file, whereas the version in the root has to be an icon file. Chances are, that's the only time you'll ever use the icon format, and many image apps don't support it. It's a weird throwback to another era, like the web equivalent of a vestigial tail.

I haven't done complete browser testing, but I know you can use a PNG and simply change the extension to .ico and it will still work in some browsers.

Edit: I tested on a domain that previously didn't have a favicon. Putting a PNG named favicon.ico at the root without an explicit <link> worked in Chrome 9, Firefox 3.6, and Safari 5. It didn't work in IE 9.

Maybe it'll work if you send the appropriate `Content-type`?

Can't you just issue a 301 redirect from /favicon.ico to /favicon.png?

IE doesn’t support any other format than ICO for favicons. Redirects, spoofed MIME types or fake file extensions won’t change that.

Is that also true for more recent versions of IE?

I found myself in a favicon pickle just the other day. I noticed one of the only non-CDN assets we had was favico.ico, which was being requested from origin servers along with every request, putting an unneeded load on Apache. Ideally we might put static assets like that on something like Nginx, but short term I was looking into how I could reduce the (albeit small) load created by favicon requests without changing the application architecture.

Ruling out Nginx, the pickle was that I should probably rewrite requests to domain.com/favico.ico to cdn.domain.com/favico.ico. But that rewrite has just as much or more httpd overhead as just serving the favico, with an extra client-side performance hit as the client has to do an extra http request to follow the 301.

I ended up with just using a <link> tag in <head>, which should at least get modern browsers off Apache's back. But I wish there was a more complete solution.

rel="shortcut icon" considered harmful

No, it isn't.

If either of these options should be considered harmful, it's the magic URL. This particular one has been responsible for countless useless requests. Another consideration is whether it's a good idea to have a standard dictate (parts of) the URL layout of a website.

As the guy who wrote the article, I agree with your point on the magic URL — in an ideal world it wouldn’t be like this. However, it is now too late. /favicon.ico has been the de facto standard for a long time and the HTML spec explicitly mentioning doesn’t really make much of a difference — it is really just standardizing what is already generally supported.

It’s time we stop complaining and start embracing this part of the URL layout as if it was robots.txt we’re talking about.

Reply on news.ycombinator.com