Most sites should just need one low-res (32px) and one high-res (192px) icon; re-use the high-res icon as an apple-touch-icon (it's supposed to be 180px, but 192px is close enough) and you're good to go.
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`.
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.
it's supposed to be 180px, but 192px is close enough
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.
Icons are rarely rendered at their intended size; there's a good chance that your browser doesn't render favicons at exactly 16px/32px, and a slim minority of Android phones have homescreen icons that are exactly 192px/500px.
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.
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.
The nice thing about using Inkscape like that is you can easily loop it and generate a number of icon sizes. Since they'll be rendered at the size specified there's no scaling artifacts. An icon might look bad because it's too busy for a 16x16 square but at least your colors won't bleed too badly.
There’s still a use case for different presentations at different resolutions. SVG can certainly address that with existing standards, but I doubt the zillion different icon formats will coalesce on a common spec within SVG. Probably the best hope is a manifest of identifiers/refs within a single SVG file.
At the current speed at which the Web Standards are "progressing", I'm predicting we'll have full HTML, CSS and JavaScript inside the favicon area any moment now.
It's been possible for a long time to use canvas to generate an image that can be transferred into the favicon, essentially using javascript to create a dynamic/animated favicon.
I do the same thing with a similar tool. I like that we can just drop a logo in one of these generators and not worry about researching the standards for each platform.
The 48×48 recommendation is bogus. I can’t think of a single thing that actually uses it at that size any more, and it doesn’t scale evenly to 32×32, which is used much more. (“I recommend sticking to a single 48×48 image, unless the one you have doesnt downscale well to 16×16 and 32×32 (becomes blurry, for instance)”, quoth the article; 32×32 will become blurry from a 48×48 downscale every single time.) That recommendation from Microsoft to include a 48×48 icon is from about ten years ago. The current recommendation from Microsoft is not to use IE.
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.
Eh, not really. If you load the SVG directly (open a .svg file, or write inline SVG in your HTML), then yes, you can run JavaScript, but when it’s loaded as an image (<img src=example.svg>, or <link rel=icon href=example.svg>), JavaScript will not be executed.
Careful with sizes=“any” on the SVG favicon. I found a few months ago that it caused Chrome to select a known size PNG favicon over the smaller SVG (with dark mode support).
>browsers download favicons in the background, so a bigger favicon image does not affect website performance;
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.
Big is a highly relative term — you can use https://webpagetest.org to see what icons each browser downloads but it's exceedingly uncommon for a site to be so aggressively optimized that the icons are a substantial amount of what any given browser downloads and the content is non-blocking and trivially cached by a CDN. Almost any site can save at least one order of magnitude more data by removing a single JavaScript dependency.
The CIRA website (Canada's .CA domain authority) used to have a badly cached 2.5mb favicon, wasting plenty of bandwidth over the years until I caught it.
This is why there is “With just three PNG images in this minimum set, you can use advanced tools to optimize their size. It solves a problem for Internet users that don’t have unlimited data plans.” note later in the article
> Even Apple, which always had some aesthetic beef with icons that don’t come from Cupertino and downplayed favicons in Safari for years, had finally given up and now displays them properly across all of its devices.
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.
Yeah I encountered this issue yesterday while working on my personal site and favicon. Extremely confusing. Firefox proofed to be much more useful for testing the favicon.
My use case is mainly that I get tired of seeing that request for a non-existing ico file in debuggers and logs when I develop. So if it is supported by my browser, it is a good start.
Are you talking about browser history? Because it seems to work just fine. If you're talking about something else, it can't be that popular. I've never heard of it, and a search is not very illuminating either.
I usually just throw emoji favicon toolkit[1] at this problem and subset to a random rotation of relevant emoji. Client-side-generated and cached favicons are possible with canvas and service workers.
Nice guide and love that it included WebPack for modern development.
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..
Question: do apple devices support favicon.ico (the old style one, a single file named favicon.ico, no pngs or json or anything else). Or do they ignore it?
I tried to search the answer online but all results were articles about the png ones instead. Thanks!
If you also find these code blocks with ligatures hard to read or understand, you can use a user style with `code, kbd, pre, samp { font-feature-settings: normal !important }` (might be a good places to set a default `tab-width` too).
I have a somewhat similar feeling. Why has favicon.ico been made into a 10 page mess? It just feels like there's too much going on for something that should be so simple.
99% of people can just ensure /favicon.ico exists in their root and be done with 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.
You have an interesting definition of “non functional” describing a UI component seen daily by billions of people which is, well, an iconic part of your site's branding.
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.
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.
Purposeful != functional, and I don't argue that they serve no purpose. My point is it's a lot of detail work (i.e. BS) for something that does no 'work' -- it's a lot of overhead for a visual cue.
It's one line of HTML (/favicon.ico is the zero-code default) for a user-interface cue which is widely used. "a lot of detail work” is only true if your internal processes for adding a static resource are phenomenally inefficient.
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.
The favicons are certainly functional - as a sufferer of 'too many tabs' syndrome, at the very moment, the only information I have about each of the ~30 tabs currently open in my Chrome browser is the favicon.
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!)
> Currently, frontend developers have to deal with 20+ static PNG files just to display a tiny website logo.
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.
Well, an arbitrary quantity of icons combined with a really smart algorithm would be better (eg: one that can distinguish whether to crop or scale in order to create small icons, and, when scaling, can handle stroke widths).
I'll bet very few icons really introduce new information once you surpass four versions.
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.