Tip: the ico can just be a renamed PNG file.
I wish people stopped cluttering their sites with a thousand useless variations.
The SVG favicon part is interesting and maybe that requires the 2 rel=icon tags.
It's important to remember that you're not just targeting browsers; lots of other software needs to parse site icons. Fancy messengers (Signal, Element, Discord, iMessage, WhatsApp), bookmarking clients, search engines, social media widgets, etc. all parse and display icons, and not all of them support SVG. Some RSS readers show thumbnails; they will only use `<link rel="icon">`, and select the higher-res icon if it's available.
Chromium DevTools has an "Application" pane that lets you preview your icon in the minimal safe clipping area; if it looks too crowded, you can specify an alternate maskable icon (unrelated to mask-icon) in your application's webmanifest with `purpose: maskable`.
I recently gave this a spin on my own site. Relevant 80-line commit message: https://git.sr.ht/~seirdy/seirdy.one/commit/b9a307a8c16d7d20...
Since that commit, I added a monochrome icon (same as mask-icon) and 512px icon (since not all programs handle svg well). Although it isn't exactly an icon, I also added an Open Graph image for all the programs that use it.
My current webmanifest is generated from https://git.sr.ht/~seirdy/seirdy.one/tree/master/item/assets... by Hugo.
The compromise you're willing to accept to save yourself the 2 minutes necessary to make a second file shouldn't really be a recommendation for others. Plenty of icons will end up with compression artefacts if you don't make a specific 180px version properly. Browsers and OSes are terrible at image scaling.
6+ years of webdev and I just learned this now. So many wasted "convert png to ico" Googles...
inkscape -o icon-48x48.png -w 48 -h 48 icon.svg
convert icon-48x48.png favicon.ico /apple-touch-icon.png
<link rel="icon" href="/favicon.ico" />
I'd remove that slash too. HTML isn't XML. If there are any user agents that don't support this, I'd consider that their problem.
Unless branding is like super important, I pretty much refuse to go any farther than this. I see no reason why it can't just be this simple.
Firefox only though, and doesn't work anymore.
Looks like it uses JS to constantly update the favicon so it matches the DOOM screen.
I get what he's saying. He's saying the browser won't wait on it before displaying actual page elements. But bandwidth is bandwidth. And bandwidth used downloading a bunch of big favicons is bandwidth not used downloading something else.
SVG icon will cover only 70%.
16×16 and 32×32 are far more important as they’re used far more—most notably, tab bars normally show icons at 16×16, which is commonly 32×32 on high-DPI displays (assuming a scaling factor of 2×). And those small sizes are also where you want to be the most careful about the rendering.
I like to craft precise 16×16 and 32×32 icons, and then generally jump straight up to 256×256 or 512×512 and let anything that wants larger than 32×32 downscale from that. (I used to go for /favicon.ico containing 16, 32 and 256, even though that bloated the file size by a handful of kilobytes, but now I’m more likely to go for /favicon.ico containing 16 and 32, and a PNG containing 256 or 512 or perhaps just shifting to SVG at this point.)
Fun fact: just as the ICO format lets you have completely distinct images for distinct sizes, an SVG file can contain multiple images for different sizes by the use of media queries; for example, you could show a tweaked icon at 16×16 and another at 32×32, and something else at all other sizes, while omitting some tiny detail below 64×64, and replacing the icon with icon-and-brand-name above 128×128. Just be aware that the media query will be matching device pixels rather than CSS pixels, which may or may not be what you’d like.
Caution should also be exercised with the prefers-color-scheme media query on SVG icons. It does not reflect whether the icon is being displayed on a light or dark background. (prefers-color-scheme: dark) hints that your icon is probably being displayed against a dark background, but it could easily still be being displayed against a light background; and with (prefers-color-scheme: light) it will be quite common for the icon to be being displayed against a dark background. You need to carefully design your icon so it works well against almost any background colour.
They can also contain JavaScript and you can use that to vary by GET parameters. A trick we use quite heavily.
sadly, no. we spent this year (and I think last) days and days trying to figure out why the icon is not getting displayed correctly in the iOS bookmarks. We thought multiple times we had figured it out, but no, not really.
I tried to search the answer online but all results were articles about the png ones instead. Thanks!
https://caniuse.com/link-icon-png
> 2If both ICO and PNG are available, will ALWAYS use ICO file, regardless of sizes set.
So it should support regular ICO regardless of png/svg existence.
It says for ios safari:
> Does not use favicons at all (but may have alternative for bookmarks, etc.).
So that means no, doesn't it?
(Not affiliated with the author, just like the tool)
I'll bet very few icons really introduce new information once you surpass four versions.
convert -resize 48x48 icon.svg favicon.ico convert -resize 180x180 icon.svg apple.png convert -resize 192x192 icon.svg 192.png convert -resize 512x512 icon.svg 512.png
Oh, only six files to to serve a freaking favicon. Thanks, that made me feel more optimistic about the contemporary www...
I use https://github.com/onderceylan/pwa-asset-generator to generate assets for PWA's(have left a message on this repo to read your article!)
I think the SVG with prefers media queries is not covering all cases, for example Chrome Anonymous dark “theme” and other user selected “themes” are impossible to check how they paint the background of the favicon area. So..the perfect solution in my view is still somewhere out there..
I’m sorry, but what? Seriously. What? I don’t get this. Why is this even a thing worth optimizing, the umber of times this even seen by someone has to be near infinitesimal.