Summary

  • Internet Explorer 5 let websites supply icons for Favorites. A 1999 Microsoft bulletin described a malformed-icon bug affecting IE 5 on Windows 95 and 98; Microsoft patched it and reported no known customer harm.
  • A 2005 W3C draft preferred a page-declared icon to a fixed root address. Today's HTML Standard permits a /favicon.ico fallback, while Microsoft's 2026 Edge note shows how a host-level icon cache can put one page's badge on another saved page.

The browser's smallest picture received a grand job: tell a human which saved page is which. In Internet Explorer 5, a site could supply the icon displayed in Favorites. The arrangement sounded harmless until the picture became input to code. Microsoft's bulletin of 27 May 1999 described an unchecked buffer in icon handling: a specially malformed favorite icon could run code on IE 5 under Windows 95 or 98. Microsoft released a patch and said it knew of no customers harmed. The badge had already become a software boundary worth defending.

Then came a less dramatic fight over the address of the badge. A common shortcut was to put an icon at the root of a website and let the browser look there. The W3C's 2005 draft guide disliked the architectural bargain. A site owner should decide what lives at a given URL; an assumed root slot narrows that freedom. It also treats a person with one page under someone else's domain as though they control the domain's front door. Many did not.

The draft's preferred move was explicit: put link rel="icon" in the document and point it to the image you chose. That let a page carry its own badge, even when its author rented only a corridor in a larger building. The W3C text was a draft, and its root-path discussion used /favicon; the current HTML rules use /favicon.ico. The principle survives the spelling: letting the page name its icon gives the author a direct say in the visual identifier.

The living HTML Standard's icon rules now call the resource an icon for a page or a site. That little “or” carries decades of work. A page may declare several candidates; the browser chooses among them using type, media and size. If an HTTP(S) page declares no icon, the browser may try /favicon.ico. The spec even keeps the old shortcut icon spelling as a historical guest at the table. Browsers gained a more explicit route without evicting the shortcut everyone had learned.

The ambiguity returned at a more familiar scale in Microsoft's March 2026 Edge explanation. On Edge's new-tab page, a saved site's icon lookup checks the exact URL, then an icon cached for the host, then a favicon service, then a letter placeholder. Microsoft's own example puts HTML pages and a PDF under one host. If the precise saved-page icon is absent, the host-level fallback may put the PDF badge on the saved home page. The reader sees a confident little emblem; the cache found a nearby address, not the exact one.

The first icon problem could crash through a parser. The later one can walk into the wrong room wearing a plausible name tag. Those are different failures, but they share a root question: who gets to attach this picture to that page? The author can declare an icon. The browser can use a fallback. A saved-links cache can reuse a neighbor's. A sixteen-pixel badge looks authoritative only after all those decisions have been made out of sight.