I experimented further, to be sure. I saved subzey's test page and icons locally and made six variations. The results are in the table below.
sizes (ICO, SVG)
Chrome 114
Firefox 114
Safari 16.3
none, none
ICO
SVG
ICO
none, any
ICO
SVG
ICO
any, none
ICO
SVG
ICO
any, any
ICO
SVG
ICO
32x32, none
SVG
SVG
ICO
32x32, any
SVG
SVG
ICO
Chrome uses the SVG if the ICO has an explicit size specified, else it uses the ICO.
Firefox always uses the SVG, and Safari always uses the ICO.
I tested with various different numbers for the sizes on the ICO, and they didn't seem to make a difference.
The upshot is to that setting an explicit size for the ICO is required for Chrome to use the SVG, no matter what is set on the SVG.
I recommend still setting sizes="any" on the SVG for when proper support is added (see the linked Chromium bugs, especially the second).
Whenever I have time, I'll update the article by referring to your comprehensive research. I'm sure many web developers appreciate your work!
Just one small question. In the table, why do you go for 32x32 for ICO, not 48x48? I'm aware you mention in your comment that it doesn't seem to matter. But I wonder whether the recommended HTML code for ICO should go with 48x48 or 32x32. Do you have any view on this?
I used 32x32 because that was the size of my PNG favicon, and I was experimenting with that being included. No other reason.
16x16 + 32x32 + 48x48 is the second-most common combination of sizes in ICO favicons (stated in that study of thousands and thousands of favicons...).
I'd probably just put the resolution of the largest size in the ICO. Or 48x48 seems a reasonable value, just because.
On a slightly different line... I'm not sure what exactly Google uses to pick an icon for Google Search results, but the minimum is 48x48. I doubt specifying that size could bias Google toward the ICO instead of the SVG, but you never know. I don't know how anyone could check, other than talking to someone rather directly involved with Search.
afaik, some versions of the Chrome browser used to pick the most appropriate size. If the browser tab needs 32x32 (which is likely), depending on the device and Chrome version, the browser might pick a 32 ico instead of the svg
at the time of writing the suggested code, with an ico size of 16 or 32, my Chrome sometimes loaded both the ICO and SVG, or just the ICO. In the newest version on my desktop (114.0.5735.134), this doesn't happen with a size of 16 or 32 any more. Haven't checked on Android this time.
last not least, afaik, Google uses the .ico for the web search results, so a bigger .ico might scale better
Hi @darrylnoakes and @xcuses ! Thanks a lot for your contributions. I'm currently rewriting the article to reflect what you have discovered. Writing forces me to think hard about the reason behind the HTML code, and now I'm not very sure why we need sizes="any" for the SVG favicon. Darryl's test suggests it doesn't really matter (at least for now) whether SVG favicon has sizes="any" or not. So is it for making the HTML code future-proof? Why would the SVG favicon without sizes="any" not be chosen if Chromium browsers strictly followed the expected logic?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I tested this in Chrome with subzey's test page and chrome-svg-favicon-bug.karlhorky.r..., and it appears to work fine!
I experimented further, to be sure. I saved subzey's test page and icons locally and made six variations. The results are in the table below.
sizes(ICO, SVG)anyany, noneany,any32x32, none32x32,anyChrome uses the SVG if the ICO has an explicit size specified, else it uses the ICO.
Firefox always uses the SVG, and Safari always uses the ICO.
I tested with various different numbers for the sizes on the ICO, and they didn't seem to make a difference.
The upshot is to that setting an explicit size for the ICO is required for Chrome to use the SVG, no matter what is set on the SVG.
I recommend still setting
sizes="any"on the SVG for when proper support is added (see the linked Chromium bugs, especially the second).Two relevant Chromium bugs:
Wow, Darryl. This is amazing!!!
Whenever I have time, I'll update the article by referring to your comprehensive research. I'm sure many web developers appreciate your work!
Just one small question. In the table, why do you go for 32x32 for ICO, not 48x48? I'm aware you mention in your comment that it doesn't seem to matter. But I wonder whether the recommended HTML code for ICO should go with 48x48 or 32x32. Do you have any view on this?
I used 32x32 because that was the size of my PNG favicon, and I was experimenting with that being included. No other reason.
16x16 + 32x32 + 48x48 is the second-most common combination of sizes in ICO favicons (stated in that study of thousands and thousands of favicons...).
I'd probably just put the resolution of the largest size in the ICO. Or 48x48 seems a reasonable value, just because.
Any reason you/@xcuses used 48x48?
On a slightly different line... I'm not sure what exactly Google uses to pick an icon for Google Search results, but the minimum is 48x48. I doubt specifying that size could bias Google toward the ICO instead of the SVG, but you never know. I don't know how anyone could check, other than talking to someone rather directly involved with Search.
Yes there are reasons why I chose 48x48:
As a note, I am using 48x48 in my project.
Hi @darrylnoakes and @xcuses ! Thanks a lot for your contributions. I'm currently rewriting the article to reflect what you have discovered. Writing forces me to think hard about the reason behind the HTML code, and now I'm not very sure why we need
sizes="any"for the SVG favicon. Darryl's test suggests it doesn't really matter (at least for now) whether SVG favicon hassizes="any"or not. So is it for making the HTML code future-proof? Why would the SVG favicon withoutsizes="any"not be chosen if Chromium browsers strictly followed the expected logic?