Favicon History: From IE5 to Modern Browser Support

The favorites icon began as one ICO

The word favicon comes from “favorites icon.” Internet Explorer associated a small Windows icon with a bookmarked page and stored favicon data alongside Favorites, which explains both the name and the early dependence on the ICO container.

The original convention was narrow: place favicon.ico at the site root and let the browser request it. That implicit request still matters for compatibility, but it no longer describes the complete icon system a current website may publish.

Connected next stepWhat Is a Favicon? The Small Icon With a Big Job for the closest prerequisite or comparison.

HTML turned the convention into explicit metadata

The rel=icon link relationship let authors declare an icon URL rather than depend only on a root probe. The sizes and type attributes later gave user agents hints about the pixels and format available in each candidate.

PNG expanded predictable transparency, and SVG provided a scalable candidate. ICO survived because one file can contain multiple raster frames and because software outside the newest browser path still recognizes the conventional root resource.

Connected next stepFavicon ICO Format: Inside Multi-Resolution Icon Files for the next connected implementation decision.

Mobile and installed apps added separate surfaces

Apple touch icons were introduced for saved home-screen web clips. Web app manifests later described icons for installed applications, launchers, task switchers, and adaptive masks. Those assets are related to a favicon but are not interchangeable with a 16-pixel tab mark.

The modern lesson is historical as much as technical: keep the dependable root fallback, declare browser candidates explicitly, and add Apple or manifest artwork only for the surfaces the site actually supports.

Connected next stepOpen the most relevant production tool and verify the decision with a working output.

Why the old conventions survived

Web conventions become durable when software can implement them cheaply and site owners can support them without negotiation. A request to /favicon.ico satisfies that test: clients can try one predictable path, and servers can answer with one small file. Even after explicit HTML became normal, removing the probe would have broken bookmarks, document viewers, intranet software, and sites that never updated their markup. Modern implementations therefore accumulated new discovery mechanisms around the original convention instead of replacing it in one clean version change.

ICO also survived because its container model solved a real rendering problem. One URL can carry separate raster frames drawn for 16, 32, 48, and larger pixel grids. A carefully edited 16-pixel frame can preserve spacing that automatic reduction would close. SVG now handles scale elegantly for supporting browser surfaces, but it does not erase software that expects ICO bytes, nor does it replace the different compositions needed by Apple and adaptive application icons.

Read the modern stack as a timeline

The current favicon package makes more sense when each file is connected to the problem introduced during its era. The root ICO covers the oldest implicit discovery path. HTML icon links let the document advertise formats and sizes. SVG answers high-density browser rendering. Apple touch artwork addresses a saved shortcut that may receive a shaped background. Manifest icons describe an installable application and can carry purposes such as maskable. Search systems add another host-level presentation layer with their own eligibility and recrawl timing.

That history also prevents cargo-cult exports. A site does not need every icon size ever documented simply because those files once appeared in generator ZIPs. It needs a tested core for the surfaces it supports, plus intentional compatibility additions. Record why each file exists, which client consumes it, and how it was verified. The historical lesson is not to preserve every artifact forever; it is to avoid deleting a working compatibility boundary before proving that no supported consumer still depends on it.

A practical historical audit

When maintaining an older site, inventory what exists before modernizing it. Fetch the root ICO, inspect every embedded frame, list icon links from the rendered homepage, locate Apple and manifest declarations, and identify which files are actually requested in production. Keep a working conventional endpoint while introducing a lean modern stack, then remove redundant legacy sizes only after the supported-client matrix passes. Preserve redirects carefully because bookmarks, PDFs, and software outside the main page can request the root icon directly. Record the old and new package hashes, public response headers, browser observations, and rollback path. This approach respects the history that made favicons compatible without freezing the site in an obsolete generator template. It also gives the history article a concrete conclusion: standards evolved by layering explicit metadata and new surfaces around a tiny stable convention, and safe modernization follows the same pattern—add observable improvements, verify consumers, and retire old artifacts only with evidence.