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:
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.
This is why it's important to design icons that look good when passed through a variety of downscaling algorithms, and to test with other browsers/devices to make sure the icon comes out right.
Clients that download multiple icons can re-use cached icons with the same URL, which is why I re-used the 192px icon as the apple-touch-icon and re-used the mask-icon as the webmanifest's monochrome icon. Of course, I tested it to make sure it looked good when downscaled.
The master icon (svg): https://seirdy.one/favicon.svg
I made this icon specifically to have a tiny footprint (176 byte 32px favicon, 785 byte 192px icon) and to look good at just about any resolution when downscaled from the original, even on an e-ink display. I admit that my approach is a bit extreme, but most sites would benefit from something similar.
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
inkscape icon.svg -w 64 -h 64 --export-type="png" --export-filename=- --export-area-page | convert - -define icon:auto-resize=64,32,24,16 favicon.ico
Firefox only though, and doesn't work anymore.
Looks like it uses JS to constantly update the favicon so it matches the DOOM screen.
(Not affiliated with the author, just like the tool)
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.
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.
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.
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
SVG icon will cover only 70%.
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!)
<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.
Is it just there in the same dir as index.html?
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..
with just <link rel="shortcut icon" href="/favicon.png" />
I tried to search the answer online but all results were articles about the png ones instead. Thanks!
> 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?
But with anything that can be done, it's nice to have a reference sheet for
how to do it well, how to do it right, and how to handle all the idiosyncrasies that exist on which clients like how to get the iPhone to grab the highest quality icon available when users add it to their homescreen.
As for the rest, welcome to distributed systems. Any time you're working on something which involves multiple codebases on different schedules you're going to have a crossover period. For the web that period is measured in years since it has many clients and billions of users.
The article covers this but if you look at the data (https://caniuse.com/link-icon-svg) there are really only two things you need:
1. An SVG icon for modern browsers
2. favicon.ico for everyone else
If you want to support higher resolution icons for Safari's pinned tabs or iOS/Android you can add those as well but that's an optimization for new way to interact with web apps which those device makers added and isn't necessary unless you expect lots of people to use that feature and your existing icon color scheme clashes with the system UI.
If you are adding PWA support to your site and don't like the way your default icon displays on some devices, you have to add one more line of HTML and one small JSON file. That is more work but it's a fraction of a percent of the work which you will need to do to make a PWA for all but the most trivial sites.
This packs far more information into the 48x48 (or whatever resolution) then trying to squeeze in a title like "Am" or "Ha" for Amazon or HN.
(Totally agree on the complexity, seems like it followed the iOS Store model of interface design!)
I'll bet very few icons really introduce new information once you surpass four versions.
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.