Can I have both a favicon.ico and a favicon.png in the root of my domain?
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 one 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. Here's an excerpt from the HTML Living Standard, section 188.8.131.52 Link type "icon":
In the absence of a link with the icon keyword, for Document objects whose URL's scheme is an HTTP(S) scheme, user agents may instead run these steps in parallel:
- Let request be a new request whose url is the URL record obtained by resolving the URL "/favicon.ico" against the Document object's URL, client is the Document object's relevant settings object, destination is "image", synchronous flag is set, credentials mode is "include", and whose use-URL-credentials flag is set.
- Let response be the result of fetching request.
- Use response's unsafe response as an icon as if it had been declared using the icon keyword.
More about this at Stack Overflow: favicon.png vs favicon.ico - why should I use PNG instead of ICO?. Note that 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 the Wikipedia article on favicons.
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)