DEV Community

Definitive edition of "How to Favicon" in 2023

Masa Kudamatsu on January 27, 2021

TL;DR In the <head> element of your HTML document, insert <link rel="icon" href="/favicon.ico" sizes="48x48" ><!-- REV...

Read full post

Rafael Pereira • Feb 27 '23

Thank you for all your research!

Doug Waldron • Mar 27 '23

This is an amazing article and definitely the most thorough that I've found!

I have some bad news though 🙁

It looks like Chromium has changed how it scores icons with the sizes="any" attribute and is now using the ICO file instead of the SVG file. See this code review: chromium-review.googlesource.com/c...

My best estimate is that started shipping with version 110.

xcuses • May 1 '23

Hi, this works for me:
<link rel="icon" sizes="48x48" href="/favicon.ico"> <link rel="icon" type="image/svg+xml" sizes="any" href="/favicon.svg">

Like this, Chrome and Edge only load the SVG Icon.

Masa Kudamatsu • Jun 19 '23

Thanks a lot for your input! (Sorry for this belated reply...)

I myself tried your suggestion for the web app I'm developing, and I can confirm that Safari on Mac OS (and iOS browsers) does use the ICO favicon with this code!

I'm planning to update the article to incorporate your suggestion once a few more people post comments on their experiences with it.

Doug Waldron • May 3 '23

Cool, have you had a chance to see how it works on Safari? (I believe Safari is currently the only reason to still include the ".ico" link.)

xcuses • May 3 '23 • Edited

Yes, that's why I included the ".ico" link. I don't own any Apple device..... if someone wants to check out if this setup works in Safari, this is the site I'm working on: ciceroneberlino.com
If someone checks it out, please let us know :)

Masa Kudamatsu • Jun 19 '23

Hi Doug! Sorry for my late reply, but thank you for your comment! It has solicited the response from xcuses below, which I can confirm works with Safari.

Darryl Noakes • May 31 '23

Seems that as of Chrome 113 at the latest, sizes="any" on the ICO isn't working anymore.

The only solution I can think of is to only link to a PNG and an SVG, based on the fact that pretty much all browsers support PNG favicons.

Masa Kudamatsu • Jun 19 '23

Hi Darryl. Thanks for your input! Please see the "Important Notice" section at the top of this article (which is added today). And let me know if the solution it offers works for you.

If you and some other people give positive feedback, I'll update the whole article to reflect this as the 2023 solution.

Darryl Noakes • Jun 20 '23 • Edited

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

Two relevant Chromium bugs:

Masa Kudamatsu • Jun 23 '23

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?

Darryl Noakes • Jun 23 '23 • Edited

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.

xcuses • Jun 23 '23 • Edited

Yes there are reasons why I chose 48x48:

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

Darryl Noakes • Jun 23 '23

As a note, I am using 48x48 in my project.

Masa Kudamatsu • Jul 2 '23

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?

Code with Ayan • Jun 28 '22

Very helpful

Tim Torres • Jul 12 '21

This is an excellent article! Really appreciate the references and reasoning. I've found a few issues with sources like CSS Tricks that I normally trust and you've covered them all.

Ben Blazak • Oct 6 '21

Really appreciate this as well!

Possible correction: just did a brief test (macos 10.14: safari 14, chrome 94) and the favicon wouldn't show up when i only had links to the svg and apple-touch-icon. I added a link to the ico (before the svg) and it works now.

Masa Kudamatsu • Nov 9 '21

Thank you for your feedback, @benblazak ! On Nov 8, I've revised the article to recommend the inclusion of the reference to the ico file, with the attribute of sizes="any" (which prevents Chrome from picking the ico file). Given your experience, I've come to a conclusion that this method is better than omitting the reference to the ico file.

Ben Blazak • Nov 10 '21

Thanks! Tested, this does indeed work with my setup :)

Masa Kudamatsu • Nov 11 '21

Great to hear that! Thanks for your feedback again!

fiiv • Oct 28 '21

Beautiful article, thanks for writing it, @masakudamatsu!

Ross Angus • Jan 13 '22

I found this article because it was linked from CanIUse. Thank you so much for putting all of this together. It's clearly been a lot of work.

Mike Robinson • May 16 '22

Boulanger (2020) claims that the type attribute is unnecessary. But Can I Use (2021a) says all the browsers that support SVG favicons (Chrome 80+, Edge 80+, Firefox 41+, Opera 67+) require "the served mime-type to be image/svg+xml".

You're getting mixed up between the type attribute in the HTML and the served mime-type, which is returned by the server when making the request to retrieve the file. The type attribute in the HTML is not needed. However the server needs to respond with a Content-Type: image/svg+xml header when the request is made.

Sergey Ponomarev • Dec 13 '23 • Edited

After tests for all browsers on all platforms I came up with the solution:

<link rel="icon" href="/favicon_48.png" sizes="48x48">
<link rel="icon" href="/favicon.svg" sizes="any">

The png 48x8 is used by Safari on both iOS and macOS.
But also it's used by Chrome and Edge when adding the site as an app. Bigger image is not really needed because it will be downscaled.
If you don't care about apps then maybe you can use here just an .ico file. I didn't tested.

If you won't specify the sizes="48x48" then Chrome will download both png and svg but show only the svg.
The mime type="image/svg+xml" is not needed: all servers anyway return a valid mime type (even BusyBox httpd) but also browsers can sniff a correct type themselves.

You can use optipng to compress the PNG file but also you minimize SVG online and even compress it with gzip -kn9 favicon.svg and serve precompressed favicon.svg.gz.

SergeVDev • Sep 17 • Edited

Hello Masa,

The code doesn't work locally, if you keep / before favicon.svg and favicon.ico. It makes your browser look for them in the root directory (say, D:\ folder in Windows) instead of your project folder.

Chan • Jun 11

Note that maskable icons should be 512x512 at least.

Maskable icons should be 512 by 512 at least. With one created, you can add it to your icons collection to improve the experience for supported devices:
web.dev/learn/pwa/web-app-manifest

Chan • Jun 10

Dude, your post is awesome!
Meanwhile, I'd like to mention this article:

If you need to pick only one icon size, it should be 512 by 512 pixels. However, providing more sizes is recommended including 192 by 192, 384 by 384, and 1024 by 1024 pixel-sized images, too.
=> When writing manifest for PWA(android), web.dev suggests you upload a variety of pixel-sized images!

web.dev/learn/pwa/web-app-manifest...

Rian Murnen • Dec 12 '23 • Edited

On Mar 14, 2022, Jen Simmons and Jon Davis posted New WebKit Features in Safari 15.4 to the WebKit blog. Under the heading “Web Apps”:

In addition, declaring icons in a web app manifest file is now supported. Safari and iOS use manifest-declared icons when there is no apple-touch-icon defined in the HTML head, and when the manifest file code for declaring the icons either omits the "purpose" key or includes "purpose": "any". Defining icons by using apple-touch-icon takes precedence over manifest-declared icons in order to provide consistent behavior for web apps that use this technique to define specific icons for iOS, distinct from other mobile platforms.

I’ve had success removing the <link rel="apple-touch-icon" href="/apple-touchicon.png" /> from the <head> and instead including the following in the Web App Manifest "icons" array:

{
    "src": "/apple-touch-icon.png",
    "sizes": "180x180",
    "type": "image/png"
}

Then on Dec. 11, 2023, Jen Simmons and Marcos Cáceres posted WebKit Features in Safari 17.2 to the WebKit blog. Under the heading “Web App icons” it states:

On macOS, users expect app icons to look sharp at a variety of sizes, ranging from 16x16px to 1024x1024px. […]

To provide the best user experience on macOS, supply at least one opaque, full-bleed maskable square icon in the web app manifest, either as SVG (any size) or high resolution bitmap (1024×1024). […]

Its worth reading the two paragraphs in full. Its not clear to me if the mention of “16x16px” in the first sentence means this applies to favicons (finally?!) or only to other use cases like Safari’s “Add to Home Screen” feature. (Update: Ugh. This may only be supported starting with macOS Sonoma.)

// WARNING: Untested.
{
    "src": "/filename.svg", // is there a filename requirement???
    "sizes": "1024x1024",
    "type": "image/svg+xml",
    "purpose": "maskable"
}

My holiday wish is for the WebKit team to publish an article explaining all web app icons, including favicons, in Safari with code samples and fallback for .

Vasyl Zuziak • Sep 20 '23 • Edited

thanks a lot for the efforts you put into this article. this is literally a lifesaver.

A tiny notice that two tags from above are missing proper version of closing tag: > instead of />

Bastien • Jan 23

What about using svg in the icons manifest? There is some talk about that but not sure if it's working everywhere.
developer.mozilla.org/en-US/docs/W...