What about having both a default root favicon.ico and favicon.png?
It's better to provide only favicon.ico and not favicon.png, because:
An .ico is a container for multiple .bmp or .png files. If you specify 1 default favicon.png, and if that favicon.png overrides the favicon.ico, you are giving up control over how the favicon looks at different resolutions and allowing the browser to do all resizing. For example, you might want the 64x64 version to contain text and the 16x16 version to not display the text at all, since at 16x16 it would be unreadable anyway.
- There is no favicon.png in the HTML5 specification, just /favicon.ico. From http://www.w3.org/TR/html5/links.html#rel-icon:
- "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."
More about this in http://stackoverflow.com/questions/1344122/favicon-png-vs-favicon-ico-why-should-i-use-pngs-instead-of-icos/1344379#1344379 (Note: the text in the chosen answer about alpha transparency is incorrect. See the 2nd answer.)
Is it true that favicons should be in the site root?
No, that's only if you don't explicitly specify the browser/device-specific
<link> tags with a favicon path. See https://en.wikipedia.org/wiki/Favicon.ico
If you don't have favicon.ico in the root consider adding one, or returning a HTTP 204 instead.
Many tools and services e.g. bookmarking sites, feed readers, web crawlers etc., request a
favicon.ico from the site root, and so recieve a HTTP 404 if it's not present. In the worst
case some frameworks will return a custom error page which is likely to be many times larger
than the missing favicon.
Is it true that the PNG must be named favicon.png?
No, a PNG favicon can be named favicon.ico.
Is it true that the ico has to be named favicon.ico?
If you don't explicitly specify its <link> tag, yes. Explicitness is best,
so we both name it favicon.ico and explicitly specify the <link> tag.
Why not prefix with "apple-touch-icon"?
If you don't specify <link> tags, iOS looks for files prefixed with
apple-touch-icon or apple-touch-icon-precomposed. Many (e.g. HTML5
Boilerplate) rely on this assumption, but:
- Explicitly specifying <link> tags is clearer and supported by Apple.
- Not hard-coding names as apple-touch-icon clears up confusion as to whether
the same icons can be reused for other purposes as-is, e.g. reusing
favicon-144.png for Windows pinned site.
Why use iOS precomposed icons?
- iOS non-precomposed icons add rounded corners, drop shadow, and reflective
shine. Sounds great in theory, but in practice the results can be very
frustrating, especially to designers.
- Non-precomposed icons don't work with Android 2.1.
Why absolute paths?
Some Firefox versions require absolute paths. Since all browsers support them,
it's the simplest choice.
Why not append a query string to force-refresh for all visitors?
Some proxies and load balancers can fail to read query strings in edge cases.
The information on this site has been made available thanks to the following sources:
- "Understand the Favicon" by Jonathan T. Neal
- "favicon-cheat-sheet" by audreyr
- The World Wide Web Consortium (W3C)