A New Standard for Website Icons

Read the proposed standard!

Motivation for a website icon standard

The world is rather used to favicons now, that they are part of the web for over 20 years. While the good old favicon.ico itself can be used with no additional configuration by placing it in the docroot of a web server, the same is not true anymore for the lots of new icon formats, that newer web features require.

To grasp a hold of the ever-changing landscape of icons, that are needed to represent a web site (or single web page) on all devices and in all situations, one needs to do extensive research. Audrey Feldroy did that and in the course a well-researched but very long article emerged for people to learn the dark art of the website icons. On the other end of the spectrum are great tools like Real Favicon Generator, that try to minimize the need for a single developer to understand the technical details.

Andrey Sitnik tried to boil down icon markup to the absolute minimum in order to support only the most popular devices. This is only marginally similar to what Mathias Bynens suggested 10 years ago on the same issue, with many changes rather subtle for people not into the research. And it is far from the humble beginnings of favicons, as the W3C suggested in 2005.

In a nutshell, it’s a mess.

In this situation Jeff Starr presents the need for a favicon standard eloquently in a blog post. This was the starting point for creating this proposed standard.

The target is to get back to the sweet spot between configuration and convention, where the most common cases can be handled with zero extra markup.

Therefore we piggyback on RFC 8615, that standardizes the /.well-known/ folder as something, that hosts files by convention.

How does it work?

The basic idea is simple: If a vendor needs a specifically sized icon for their platform, they register a name for it. This registry serves as central place to find out, which icons we need.

For example, imagine PearGlyph Inc. introduces a new device, the TouchMagic tablet. For progressive web apps it needs icons in a pixel format, that are exactly 272 pixels wide. PearGlyph Inc. would then register the following icon names:

pearglyph-touchmagic-272.jpg
pearglyph-touchmagic-272.png

If we want to support the TouchMagic device, we put an icon with such a name in the folder /.well-known/icons/ in our docroot.

The standard adds a short list of default icon names, too. Most prominently, it introduces

/.well-known/icons/favicon.svg

as default favicon to be used. The reasoning is, that using a vector format like SVG satisfies the most needs in parallel.

For backwards compatibility a redirect from /favicon.ico to

/.well-known/icons/favicon.ico

will signal support for the standard to browsers.

How does a client find icons? In order not to fish in muddy waters and send requests for potentially hundreds of matching icon names the standard demands a file index.txt, that is a plain-text list of supported icons.

Such a list can be compiled rather quickly by sysadmins by running the command

find -L . -type f -printf '%P\n' > index.txt

in a shell in the /.well-known/icons folder (on systems, that understand the -printf flag of find).

Quick start: How do I support the standard?

If you have an existing favicon.ico file already live on your server, all you need to do are three quick things:

1. Move the file:

    mkdir -p .well-known/icons/
    mv favicon.ico .well-known/icons/
   

2. Create the index file:

    echo "favicon.ico" > .well-known/icons/index.txt
   

3. Redirect requests from /favicon.ico. Example code for Apache .htaccess files:

    RewriteEngine On
    RewriteRule ^favicon.ico /.well-known/icons/favicon.ico [L]
   

That’s it. Now you support the standard while being 100% backwards-compatible.

If you cannot do step 3 in your setup, you can add the following line in your HTML files for the same effect:

<link rel="shortcut icon" href="/.well-known/icons/favicon.ico">

How to change icons quickly?

This is something the standard also strives to make as painless as possible. You can place a set of different icons in a sub-folder of /.well-known/icons.

Let’s take a common use case: You want a different favicon on the development installation of your site from your live site. The solution with the website icon standard is to create a folder

/.well-known/icons/dev/

and place there a development version of your favicon. In the HTML files you activate the set with a single line,

<meta name="icon-set" content="dev">

This is all. Now your dev server reminds you reliably by means of a favicon.

Who are we?

We are developers and designers who want to change the status quo of website icons. We want to make all our lives easier by adding opt-in conventions for the ever-expanding use of favicons.

The standard was initiated by Manuel Strehl.

Come aboard! Make your opinion and experience heard by opening a new issue or joining a discussion.

Websites that already support the website icon standard

icon	website
	hyperform.js.org (index.txt)
	manuel-strehl.de (index.txt)
	kinetiqa.de (index.txt)

Add your site: Open an issue or send a pull request with the link to your website and to the icon.