How Browsers Choose Which Favicon to Display

Selection starts with the current document

A browser reads icon links associated with the active document and evaluates the href, rel value, type hint, and sizes hint. The HTML standard allows several candidates; it does not promise that source order alone decides the winner in every user interface.

A declared type can let a browser skip a format it does not support, while sizes should describe dimensions that really exist. SVG normally uses sizes=any. Incorrect hints make debugging harder because the browser may discard a candidate or choose a less suitable fallback.

Connected next stepFavicon HTML Link Tags: Complete Code Reference for the closest prerequisite or comparison.

The destination surface changes the choice

A tab, bookmark, pinned tab, mobile shortcut, and installed PWA are separate consumers. Ordinary rel=icon candidates serve browser surfaces; apple-touch-icon and manifest icons have their own discovery paths and artwork expectations.

Browsers may retain a previously selected icon in a surface-specific cache. A surprising result is therefore not proof of a different selection algorithm until the current HTML, public bytes, and a clean test context have been checked.

Connected next stepFavicon Formats Compared: SVG, PNG and ICO for the next connected implementation decision.

Build an observable selection test

Give each candidate visibly different test artwork, then record which one appears in each browser and surface. Request every URL directly and capture response type, dimensions, redirects, and final bytes before interpreting the visible result.

After the test, restore one coherent brand system. Deliberately different fixtures are diagnostic tools, not a production recommendation, because inconsistent candidates make bookmarks and installed icons look like different products.

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

Candidate hints are not commands

The type attribute is a declaration about the linked resource, not a way to force selection. A browser can use it to skip an unsupported format before fetching, but dishonest metadata may cause a useful candidate to be ignored. The sizes attribute is similarly descriptive. It lists raw pixel dimensions actually present, or any for a scalable icon. Writing an aspirational size does not create those pixels. For ICO, multiple values can describe embedded frames; for a PNG, the declared value should match the decoded canvas.

Media conditions and multiple icon elements can add another decision layer. A theme-aware SVG may adapt internally, while separate link elements may advertise light and dark candidates. Support and cache behavior can differ, so a fallback should remain legible even when the preferred branch is not selected. Keep declarations small enough to understand. A head containing many redundant candidates makes it harder to know which URL won, increases opportunities for stale files, and turns browser differences into an unrepeatable guessing exercise.

Create a selection matrix instead of anecdotes

A useful test matrix names the browser version, operating system, page URL, surface, candidate inventory, selected artwork, and cache state. Tabs, bookmarks, pinned tabs, history, shortcuts, and installed applications should have separate rows. Give test candidates unmistakably different colors or shapes, then repeat on a fresh hostname or profile so an earlier favicon cannot masquerade as current behavior. Capture the network log alongside the visible observation; a display result without the fetched URL is incomplete evidence.

Production verification then reverses the test setup. Restore visually consistent brand artwork, retain only purposeful candidates, and ensure every declared file returns the expected bytes. Test navigation between nested routes because relative paths can change the candidate set without changing the template source. Finally, document what is not guaranteed. One passing version does not establish permanent behavior across all browsers, and no selection test can force a search engine or saved shortcut to refresh on the same schedule as a browser tab.

Debug selection in a fixed order

Use a fixed diagnostic order whenever the visible icon is unexpected. First capture the rendered icon elements and resolve their absolute URLs. Next request each candidate and confirm final status, type, dimensions, and bytes. Then identify the exact browser surface and reproduce it in a fresh profile. After that, remove candidates in a staging copy until the selected resource is unambiguous. Finally, reintroduce only the fallbacks the support matrix requires. This order separates author markup from transport, decoding, selection, and caching. It also prevents a common mistake: changing image pixels when the browser never fetched that image. Save the reduced test case with browser and operating-system versions. If implementations disagree, document the difference and choose a fallback stack that stays recognizable in both results instead of trying to force one undocumented algorithm across every client.