Hacker News new | past | comments | ask | show | jobs | submit login
How to Favicon in 2021: Six files that fit most needs (evilmartians.com)
351 points by iskin 5 months ago | hide | past | favorite | 82 comments

Unless you have a PWA, you only need a /favicon.ico and the touch PNG icon. The browser will fetch them automatically, no tags required.

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.

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

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.

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.

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.

> Tip: the ico can just be a renamed PNG file

6+ years of webdev and I just learned this now. So many wasted "convert png to ico" Googles...

It takes me a few minutes from getting an favicons from an SVG using Inkscape and Imagemagick, rasterizing it with:

    inkscape -o icon-48x48.png -w 48 -h 48 icon.svg
...plus the other dimensions required and generating an ico with

    convert icon-48x48.png favicon.ico

I'm doing something really similar, but creating a multi-resolution 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
Pretty sure that it's more efficient to have multiple files but, whatever. Multiple favicons annoys me.

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.

It doesn't work in IE6 though!

I sincerely hope you are being sarcastic. Otherwise, you have my sympathies for having to deal with that in 2020/2021.

SVGs are such a better choice for favicons that I hope they become so dominant that we can drop the rest.

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.

The default path for the PNG touch icon is: [1]

[1]: https://developer.apple.com/library/archive/documentation/Ap... "Configuring Web Applications"

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.

At some point it was possible to play Doom as favicon.

Firefox only though, and doesn't work anymore.


Still works here, using Firefox 84 on Ubuntu. That's pretty cool.

Looks like it uses JS to constantly update the favicon so it matches the DOOM screen.

I've seen a game there, Defender of the Favicon: http://www.p01.org/defender_of_the_favicon/

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.

You can already put CSS in an SVG favicon. That's one way to adapt a favicon to a user's native dark mode/light mode preference.

Nice writeup. I used this a few times and cam recommend it if you want to have everything auto-generated: https://realfavicongenerator.net/

(Not affiliated with the author, just like the tool)

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.

Fair point. I replaced 48 → 32 in the article.

> an SVG file can contain multiple images for different sizes by the use of media queries

They can also contain JavaScript and you can use that to vary by GET parameters. A trick we use quite heavily.

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

Yeap, size=any works for the case when you do not have other PNG images as I recommend

Cool, and thanks for this well reasoned writeup. Looking forward to deleting some code.

>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

Browsers won't always download all available icons if they don't need to. To test a browser, open its network monitor and hard-refresh the page.

or bandwidth that would not be used otherwise - I guess though most sites nowadays would make that unlikely.

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

At least on macOS Safari’s icon cache is VERY long-lived

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.

I'm only serving one single favicon.ico on my website. I guess I'm doing it wrong.

A map of Favicons by Internet footprint:


If you have imagemagick installed and an svg icon, you can use the following to generate the other 4 types:

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

A single SVG icon will get one to 88% browser support, which depending on use case may just be good enough.


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.

I usually use a inlined base64 encoded favicon for that purpose like this: https://davidwalsh.name/blank-favicon

Not 88%. Partial support on this Can I Use page is about different icon type in Safari.

SVG icon will cover only 70%.

Yeah, seems one has to provide a png fallback for Safari, otherwise it will not render a icon at all.

> Instead of serving dozens of icons, all you need is just five icons and one JSON file.

Oh, only six files to to serve a freaking favicon. Thanks, that made me feel more optimistic about the contemporary www...

Thank you for the article. It is certainly alluring to reduce the number of generated images linked in the <head> in PWA apps.

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 don't see much point providing anything but the first.

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

Small 48×48 icon in favicon.ico will not work on browser recent websites page (which is pretty popular feature)

One of the few reasons got the .ico file format to exist is that you can put multiple icon sizes in it, so just include some larger variants.

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.

It's the "Recent Sites" list that appears e.g. when you open up chrome or a new firefox tab by default.

Or literally just focus the URL bar in mobile Safari, and I suspect most other mobile browsers are similar.

I omit the favicon part from the HTML completely, the browsers still request the favicon.ico even when it's not specified.

In situations where I can control all responses for a host, I will probably start doing that as well.

Wait, but how do you serve it up?

Is it just there in the same dir as index.html?

Yes, I just place a file called favicon.ico into the root folder of the domain.

I believe it has to be at /favicon.ico.

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.

1. https://github.com/eligrey/emoji-favicon-toolkit

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

You also always need a favicon.ico in the root folder as many things will look for it — bookmarking services, crawlers etc.

I never got the point of multiple favicon.png. I only use one, won't it be used by default for all purposes?

On my website the favicon doesn't appear when I try to create a shortcut on Android home screen - looks like the manifest is necessary for that?

I just tried and it did for me. From Chrome

with just <link rel="shortcut icon" href="/favicon.png" />

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!

See the caniuse for PNG favicons. Note 2 describes the behaviour tied to safari/webkit:


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

Thanks for the link!

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?

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

Another example of the www getting worse every year.

Care to expand? Just negativity is not very useful for conversation.

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.

I think the point is look at all the BS complexity just to display a non functional icon.

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.

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.

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

It’s been this way for at least 8-10 years. Nothing has changed except it’s gotten more stable and simpler thereby.

Could we just have a single fav icon and use a better algo to simplify it?

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.

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

Just used a website to generate all the files... not a lot of work

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact