skip to content

What does a `<link rel="icon">` tag in a page's `<head>` do, and what happens if a site ships no icon link at all?

level: juniorimportance: should knowfreq 42%

answer

  1. the picture the tab strip shows
  2. declared in head, renders nothing
  3. browsers ask for one even unasked
  4. a root path everybody assumes
  5. shortcut is a dead keyword

basics

~10 s

A link rel=icon tag names the image a browser uses for the tab, bookmark and history entry. Without one, browsers still request /favicon.ico at the site root and use that file if it exists.

solid answer

~50 s

`<link rel="icon" href="...">` is the declarative way to tell a browser which image represents the document — tab strip, bookmarks, history, and often the task switcher. The `href` can point anywhere; the file does not have to be called `favicon.ico`, and `type` plus `sizes` describe the candidate so the browser can pick sensibly. If you declare nothing, browsers fall back to an implicit `GET /favicon.ico` at the origin root, which is why a site with no icon markup still shows a 404 for that path in the network log. A modern minimal set is one SVG icon, one ICO or PNG fallback, and an `apple-touch-icon`; the long generator-produced block of `rel="shortcut icon"`, `mask-icon` and `msapplication-*` tags is legacy and mostly deletable. `rel="shortcut icon"` is a historical spelling — the `shortcut` keyword carries no meaning today.

code

html · 7 lines
html
<head>
  <meta charset="utf-8">
  <title>Example</title>
  <link rel="icon" href="/favicon.svg" type="image/svg+xml">
  <link rel="icon" href="/favicon.ico" sizes="any">
  <link rel="apple-touch-icon" href="/apple-touch-icon.png">
</head>

go deeper

for a junior

Know that the tag lives in the head, points at any image URL you like, and that browsers also try /favicon.ico on their own when nothing is declared.

for a middle

Be ready to explain what type and sizes tell the browser, why rel="shortcut icon" is meaningless today, and which of the legacy generator tags you would delete from a head block.

for a senior

Expect to be asked why a rebranded icon still shows the old logo in users' tabs — talk about long-lived icon caching at a stable root path and versioning the href to force a refetch.

for a principal

Own the call on how much icon surface a product actually maintains: every extra platform-specific asset is another file to re-cut at every brand change, so justify each one by real usage rather than copying a generator's output.

## What the tag is for An icon link is metadata about the *document*, so it lives in `<head>` next to `<title>` and the other `<meta>` and `<link>` elements. It answers one question for the browser: when I need a small picture to stand for this page, which file do I fetch? The surfaces that consume it are all browser chrome, not page content: the tab strip, the bookmark list, the history entries, the address-bar suggestion list, the OS task switcher, and on some platforms the desktop shortcut. Nothing in the page's layout is affected — an icon link renders nothing. ```html <link rel="icon" href="/favicon.svg" type="image/svg+xml"> <link rel="icon" href="/favicon.ico" sizes="any"> <link rel="apple-touch-icon" href="/apple-touch-icon.png"> ``` ## The implicit /favicon.ico request The convention predates the `<link>` markup: browsers request `/favicon.ico` from the origin root when a document declares no icon of its own. That is why a brand-new site with no icon markup shows a `404 /favicon.ico` line in the network panel or the server access log — nobody wrote that request, the browser invented it. Two consequences follow. First, dropping a `favicon.ico` at the web root is enough to get an icon with zero markup. Second, if you *do* declare icons, the implicit request generally stops mattering, because you have given the browser a better answer. The fallback is per-origin, not per-page, so it cannot vary between routes the way a declared link can. ## The attributes that actually do something - `rel="icon"` — the only keyword you need. `rel="shortcut icon"` is a legacy spelling from the Internet Explorer era; `shortcut` is not a defined link relation and browsers simply ignore it, treating the tag as `icon`. Writing plain `icon` is correct. - `href` — any URL, any filename, any directory. The name `favicon.ico` is a convention for the implicit fallback only. - `type` — the MIME type of the candidate, e.g. `image/svg+xml`, `image/png`. It lets a browser skip a format it cannot decode without downloading it first. - `sizes` — the pixel dimensions the file contains, like `sizes="32x32"`, or the keyword `sizes="any"` for a format that scales (or an ICO holding several sizes). ## What to ship in practice Icon generators still emit a wall of tags. Most of it is dead weight in a modern codebase: - `<link rel="apple-touch-icon">` — still worth shipping. Safari on iOS uses it for the home-screen icon; a 180×180 opaque PNG is the usual asset. - `<link rel="mask-icon" href="..." color="...">` — a monochrome SVG for Safari's pinned-tab feature. Narrow, Safari-only, harmless to drop. - `<meta name="msapplication-TileImage">` / `msapplication-TileColor` and the `browserconfig.xml` they point at — Windows tile support from the Internet Explorer / Edge-legacy era. Delete them. - A dozen `rel="icon"` PNGs at 16, 32, 48, 96, 192… — an SVG covers every size in one file, with an ICO or a single PNG behind it for browsers that will not render an SVG icon. A reasonable modern set is three lines: the SVG icon, an ICO fallback, and the Apple touch icon — plus `<link rel="manifest">` if the site wants an installable identity. ## Things that bite **Caching.** Browsers hold icons for a long time, and the icon is often served from a stable root path with a long-lived cache policy. After a rebrand the old icon can persist in tabs for far longer than the rest of the deploy. Giving the file a versioned name or a query string in the `href` sidesteps it, which is one more reason to declare the link explicitly rather than lean on the root fallback. **Placement.** The link belongs in `<head>`. An icon link in `<body>` is not part of the document metadata and should not be relied on. **Per-page icons.** Because the icon is declared per document, different sections of a site *can* declare different icons — a real (if rarely used) capability that the `/favicon.ico` fallback alone cannot give you. **It is not accessibility markup.** The icon has no `alt`, is not exposed to assistive technology as page content, and is never a substitute for a proper `<title>`. Screen-reader users identify a tab by its title.

  • If the file does not have to be named favicon.ico, why do so many sites still put one at the root?
    Because the implicit fallback request goes to `/favicon.ico` at the origin root, a file there gives an icon to anything that never parsed your markup — crawlers, feed readers, chat link previews, older clients — and it also silences the 404 that otherwise shows up in access logs. It costs one small file, so it stays.
  • Where should icon links sit relative to the rest of the head, and does the order matter for performance?
    They go in `<head>` with the other metadata. Order among the icon links themselves does not change correctness — the browser evaluates the candidate set, it does not take the first one. What does matter is not putting them ahead of `<meta charset>` and the viewport tag, since those affect parsing and layout and should come first.

saying these in an interview costs you the question

  • Thinks the icon file must literally be named favicon.ico
  • Says rel="shortcut icon" is required for old browsers
  • Believes no icon link means the browser makes no icon request
  • Claims the icon link belongs in the body
  • Ships a generator's twenty-tag block without knowing what any of it does

context

resolving links…