Media type designations for favicons

This note supplements the Wikipedia article on favicons. My focus here is specifically on media type designations for ICO images and for PNG images and their intepretation when used as values of the type attribute of favicon links served to Firefox (specifically 1.5.0.7) and IE (specifically 6.0.29) browsers.

IANA is the source of record for terms used on the web for such things as media types and provides sources of reference for these terms. RFC2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, specifies that MIME media types will be assigned and listed by IANA. The following IANA rules for naming MIME media types are particularly helpful for understanding the media type designations used for webpage favicons.

Experimental names

A media type designation beginning with the characters "x-" is considered an experimental media type name. RFC2046 tells us:

A media type value beginning with the characters "X-" is a private value, to be used by consenting systems by mutual agreement. Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-".

Note: Publicly specified values are terms enrolled with IANA.

Proprietary names

RFC2048, Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures, tells us that a vendor may register a media type name:

…for media types associated with commercially available products … A registration may be placed … by anyone who has need to interchange files associated with [a] particular product. However, the registration formally belongs to the vendor or organization producing the software or file format. Changes to the specification will be made [only] at their request … Registrations [made by vendors] will be distinguished by the leading facet "vnd.". That may be followed, at the discretion of the registration, by either a media type name from a well-known producer (e.g., "vnd.mudpie") or by an IANA-approved designation of the producer’s name which is then followed by a media type or product designation (e.g., vnd.bigcompany.funnypictures).

ICO media type designations

Vendors are generally disposed to accomodate IANA terms but — as in this case — are not bound to them. Microsoft devised the ICO image format to allow one image file to bundle images of different sizes for the same icon; this format was intended for internal use by a commercially available product, the Windows operating system. Microsoft registered this format with IANA as image/vnd.microsoft.icon; this is the official name of this media type and this name is controlled by Microsoft.

Other makers of browsers accepted this image format to ensure their ability to render web pages written for IE browsers. However, one can imagine how galling it is for these vendors to see the name of their Microsoft competitor each time such an icon is specified. They would prefer to designate this format simply as image/icon, which would be consistent with IANA media type names for other common image formats. Unfortunately, Microsoft has registered the image/vnd.microsoft.icon name for this format. To form a competing, valid media type name that abides by IANA naming rules, other vendors converged on the alternate designation image/x-icon. In IANA’s terms, the image/x-icon designation is technically an unregistered experimental name: this name will not be found among IANA’s registered media type names but it will pass lexical and syntactic scrutiny because it conforms to IANA’s rules for constructing a valid media type name. The plain image/icon form is thus an informal designation, even though it is the only one of the three media type designations that is consistent in form with IANA names for other common image formats (e.g., image/cgm, image/gif, image/jpeg, image/png, image/tiff).

The last update of Microsoft’s registration of vnd.software.icon complains of a proliferation of alternate designations for Microsoft’s icon format: While "image/x-icon" is also used, this registration intends to finally clarify the media type for this file format. In spite of this complaint, IE allows other media type designations for this format. Indeed, default IIS 5.1 MIME map settings include image/x-icon but not image/vnd.microsoft.icon! Both IE and Firefox accept all media type designations listed in this table of webpage favicon media type designations:

media type	name status
type="image/vnd.microsoft.icon"	registered IANA name
type="image/x-icon"	experimental IANA name
type="image/icon"	informal designation
type="image/xcon"	imaginary designation

How Firefox and IE use media type names

I made up the image/xcon designation to test how Firefox and IE process favicon links. Both browsers accept this fictitious media type designation without comment. Both browsers also correctly render the webpage favicon image specified by the favicon link.

In fact, neither Firefox nor IE seem to mind if the entire type attribute is omitted from the link tag for a webpage favicon. Both browsers appear to ignore the type attribute altogether; they appear to pay attention only to the extension of the image file name. As it turns out, neither browser actually much cares about the image file name extension either.

Although Firefox does it one way and IE does it another, neither Firefox nor IE rely upon given file extensions or supplied MIME types to determine the actual MIME type of an image. For images loaded via <img src>, Mozilla’s image library will do content sniffing (never extension sniffing) to find out the real type of the image. In other words, Mozilla peeks into the image file itself to determine the appropriate image type. Firefox correctly displays a webpage favicon identified by <link rel="icon" href="images/favicon.icx" /> — that is, with an unknown file name extension and without a type attribute; we must then suspect that such content sniffing also occurs for images loaded as webpage favicons.

Something quite different occurs in IE given this flawed link tag. As this screen capture shows, IE correctly determines the true image type for the .icx file loaded via the link tag but is flummoxed by the invalid file extension when it is loaded via an <img> tag. This suggests that IE assumes that any file loaded via <link rel="shortcut icon" …/> must be an ICO image (i.e., of MIME type image/vnd.microsoft.icon).

Do other browsers or user agents care? Yes, they do. For one, Opera 9.02 will not load a webpage favicon with an unknown file name extension — but, like IE and Firefox, Opera does ignore the favicon link’s type attribute.

Discussion

Neither Firefox nor IE necessarily use either a webpage favicon image’s file name extension or its specified media type designation to determine an appropriate MIME type. In spite of this observation, a favicon link tag should be completely and correctly specified for several reasons:

• clarity: The favicon.ico naming convention exists and is well understood both by humans and user agents. To use a different file name for a webpage favicon is to invite unjustifiable confusion. (But see note below.)


• correctness: The type attribute should be specified because the default MIME type is text/plain. To omit the type attribute is to falsely assert that a webpage favicon image file contains plain text data.


• validity: The DTD for XHTML specifies:
  

  <!ENTITY % ContentType "CDATA">
      <!-- media type, as per [RFC2045] -- >

  
  (Even though strict XHMTL 1.0 validators — such as the W3C validator, the WDG validator, and Page Valet validator — do not presently complain about invalid or badly-formed IANA names, the XHTML DTD gives them every right to do so in the future.)


• risk mitigation: As we see with Opera, we cannot generalize from today’s behavior of two specific user agents to other user agents today or in the future. We mitigate risk by adhering to web standards and by making explicit our assumptions.

Note that this observation about clarity does not preclude extending the name favicon.ico using accepted domain naming conventions. By these conventions, terms in a name start with the most specific on the left and end with the most general on the right. Thus, the favicon.ico convention may be followed by extending this name to the left with increasingly specific terms. This table shows how such webpage favicon image file names might be constructed:

web page	favicon file
www.acme.com/about/directions.html	...acme\favicons\directions.about.favicon.ico
www.acme.com/assembly/directions.html	...acme\favicons\directions.assembly.favicon.ico
www.acme.com/jobs/apply/directions.html	...acme\favicons\directions.apply.jobs.favicon.ico

The real question is the choice of a valid IANA name for the media type designation: image/vnd.microsoft.icon or image/x-icon. Strict constructionists must use image/vnd.microsoft.icon. Further, should a separate link tag offer a PNG webpage favicon to reasonable browsers, image/vnd.microsoft.icon reminds a human reader that this webpage favicon is offered specifically to IE browsers.

PNG media type designations

Media type designation for PNG files is simple. IANA records image/png as the registered media type name for this image format.

media designation	name status
type="image/png"	registered IANA name
type="image/x-png"	experimental IANA name

Interestingly enough, Microsoft appears to recognize image/x-png as a MIME type but not image/png. However, neither image/png nor image/x-png is included in IIS 5.1’s default set of MIME types. In spite of the IANA registration of image/png, Microsoft apparently still considers the PNG image format to be experimental, which seems to be confirmed by IE’s continued problematic rendering of PNG images. (See the screenshot above: IE has rendered opaque a transparent PNG image.)

Recommendation

I recommend this approach, expressed in XHTML, to provide an ICO webpage favicon for IE while providing a PNG webpage favicon for other browsers:

<link rel="shortcut icon" href="favicon.ico" type="image/vnd.microsoft.icon" />
<link rel="icon" href="favicon.png" type="image/png" />

The HTML 4.01 specification says: These link types are case-insensitive, i.e., "Alternate" has the same meaning as "alternate". However, XHTML 1.0 says that element names, attribute names, values from pre-defined sets are to be written in lower case. Therefore favicon links should be written in lower case to be compatible with both HTML and XHTML.

The first favicon link specifically targets IE while the second favicon link targets Firefox and other reasonable browsers. The order of these tags is important. As the Wikipedia article points out, IE incorrectly understands the rel value "shortcut icon" in the first tag as a single term instead of two terms separated by a space character. Because IE does not understand the value "icon", IE ignores the second tag.

In contrast, Firefox appears to correctly parse the rel value in the first tag into two separate terms. Not knowing what to do with the term shortcut, Firefox disregards it. Firefox does know what to do with "icon", so it requests the webpage favicon identified by the first favicon link. Firefox then requests the webpage favicon identified by the second favicon link.

Thus, IE ignores the second favicon link and loads only the favicon.ico file, while Firefox requests both files but only caches and loads the second one, favicon.png.

Additional note on webpage favicon link rel attribute values

Neither commonly used rel attribute value — "shortcut icon" or "icon" — is a standard value of the rel attribute of a link tag. The HTML 4.01 Specification says: Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details. I have not found any evidence that such a profile has been defined or used for favicon links. Such a profile reference would look something like this:

<head profile="http://www.acme.com/profiles/webpageFavicons">

Favicon terminology

Following the lead of the Wikipedia article on favicons, I define the term favicon to mean an icon displayed by a browser anywhere outside its viewport to signify a website or webpage. A browser’s viewport is the area of a browser window where the current page is rendered.

Favicon is a taxonomic term that sweeps together different kinds of images manipulated in different ways by different products. More specific terms are useful to distinguish different classes of favicon that may be characterized by mutually-exclusive properties. I have absconded with words from the Wikipedia definition to form the terms described in this table of Favicon Terms. A favicon link is an HTML link tag with with a rel attribute value of either "icon" or "shortcut icon".

favicon term	invoked by	applies to	source	image type see note	persistence	display context
webpage favicon	favicon link	specific page in a web domain	any URL	ICO GIF JPG PNG TIFF	cached	current page
website favicon	absence of favicon link	any page in a web domain without a webpage favicon	favicon.ico in a web domain's root folder	ICO	cached	current page
bookmark favicon	saving a webpage favicon or a website favicon	any page in a web domain	any URL	ICO GIF JPG PNG TIFF	saved	hyperlink

Note: The MIME type for a website favicon must be image/vnd.microsoft.icon or image/x-icon. The MIME type for a webpage favicon (a) may designate any image format native to a browser and (b) should be a well-formed IANA media type name, preferably a registered name.

Note: There may be other constraints on bookmark favicons, such as a limit on the physical size of the image file.

Note: I received 13,300,000 Google hits for favicon, 2,550,000 for page icon, 838,000 for site icon, 520,000 for bookmark icon, 95,500 for favorites icon, and 18,700 for domain icon. By this measure, favicon is the most widely used of these terms. In contrast, Google reported only 20 hits for webpage favicon, 617 for website favicon, and 438 for bookmark favicon, so I feel comfortable expropriating these terms.