Why your favicon isn’t showing up (and how to fix it)

10 min read

You uploaded a favicon, pasted the code, refreshed the page — and the tab still shows the old icon, a generic globe, or nothing at all. This is one of the most common favicon problems, and it is rarely mysterious. A browser has to find a declaration, download a file, accept its format and size, and then decide not to use the copy it cached last week. A failure at any one of those points produces the same blank-looking tab.

The fastest way to fix it is to stop guessing and work through those points in order. Do not start by regenerating files at random: first find out where the icon is missing, because a favicon that is absent from Google Search is a different problem from one that is absent from your own browser tab.

First, narrow down where it is not showing

Before changing anything, answer three quick questions:

  • Is it missing everywhere, or only in one place? Check a browser tab, a bookmark, Google Search results, and — if you care about them — an iOS or Android home-screen shortcut. Each of these uses a different icon or a different cache.
  • Do you see the old icon or no icon? An old icon almost always means caching. No icon, or your platform’s default placeholder, usually means the file is missing, unreachable or never declared.
  • Is it missing on every page or only some? If the home page works but other pages do not, those pages are probably missing the markup, using a different template, or resolving a relative URL from the wrong folder.

Also test the live site — not a local copy or a staging URL behind a login — and the exact host visitors use: example.com and www.example.com are fetched separately and can show different results until both are updated.

Step 1: Open the icon file itself

This single test separates most causes. Work out the icon URL — usually https://example.com/favicon.ico, or whatever your href points to — and open it directly in the browser.

  • You get a 404. The file is not where the page says it is. Check that it was uploaded to the public web root (or your framework’s public folder and included in the build output), that the file name matches exactly — servers are often case-sensitive, so Favicon.PNG is not favicon.png — and that a site installed in a subfolder is not pointing at the domain root.
  • You get a login page, an HTML page or a redirect loop. The URL exists but does not serve an image. Authentication rules, redirect rules and some security plugins happily intercept /favicon.ico; the browser then discards what it receives.
  • The old icon opens. The file on the server is stale, or a CDN in front of it is still serving the previous version. Replace the file, then purge the CDN cache for that URL.
  • The new icon opens. Your file and hosting are fine. The problem is in the declaration or in caching — keep reading.

Browsers request /favicon.ico by convention even when a page declares nothing, which is why an ICO at the root is still worth having: it also covers non-HTML documents such as PDFs. But that convention is a fallback, not a substitute for declaring your modern icons.

Step 2: Check the declaration in your page

View the source of the live page (not your editor) and look in the <head> for lines like these:

<link rel="icon" type="image/svg+xml" href="/favicon.svg" />
<link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96" />
<link rel="shortcut icon" href="/favicon.ico" sizes="32x32" />
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png" />
<link rel="manifest" href="/site.webmanifest" />

The usual mistakes are mundane: the snippet was added to one template but not the one serving the page; a theme, plugin or site builder injects its own favicon tags on top of yours, so the browser picks the other set; the href is relative (href="favicon.png") and breaks on pages in subfolders; or the declared type and sizes do not match the actual file, which some browsers treat as a reason to skip it. If you see two competing sets of tags, remove the one you do not control rather than adding a third.

On framework sites, check the convention before pasting blindly: Next.js generates these tags from specially named files in the app folder, while React apps reference files from public/index.html. See which favicon files you need for what each line does.

Step 3: Make sure the file itself is valid

A file can download successfully and still be rejected. Renaming a JPEG to favicon.png does not make it a PNG, and a truncated or mis-encoded upload will fail silently. Open each icon and confirm it really is the format and size its name and markup claim. The set that covers current browsers is small:

  • An SVG favicon for modern desktop browsers (valid XML, with a viewBox), plus a 96×96 PNG fallback.
  • A favicon.ico containing at least 16×16 and 32×32 images, for legacy tools and direct file views.
  • A 180×180 apple-touch-icon.png that is fully opaque — iOS fills transparent areas with black.
  • 192×192 and 512×512 PNGs declared in site.webmanifest for Android, with the important content inside the central maskable safe zone.

If your files fail these checks, the quickest repair is to rebuild the package rather than patch files one by one. The free favicon generator produces exactly this set from one image, with the matching HTML, and previews it in tabs and search results before you download — useful, because an icon that is technically valid can still be unreadable at 16 pixels.

Step 4: Defeat the favicon cache

Suppose the file is online and declared correctly, yet your browser stubbornly shows the old icon. That is normal: browsers keep favicons in a separate, persistent cache that a regular refresh — and often even a hard refresh of the page — does not clear. They do this because favicons are requested constantly and change rarely.

Work through these, cheapest first:

  1. Open the icon URL directly and hard-refresh it (Ctrl+F5, or Cmd+Shift+R on macOS). That refreshes the cached copy of the file itself.
  2. Test in a private/incognito window or a second browser. If the new icon appears there, your deployment is correct and only your main browser’s cache is behind. That is a diagnosis, not a problem your visitors will have.
  3. Version the URL. Change /favicon.svg to /favicon.svg?v=2 in your markup (and use a new version each time you replace the icon). A new URL cannot be served from the old cache entry. The generator can append this version for you.
  4. Purge the CDN and check for a service worker. If a CDN sits in front of your site, purge the icon URLs there; an in-browser test bypassing the CDN can confirm this is the layer at fault. Installed web apps may also keep showing a cached icon until the app’s stored data is refreshed, so re-adding a home-screen shortcut is a fair test on mobile.

One warning: versioning works because the URL changes, so do not change it again casually once things settle. As the next section explains, Google in particular prefers a favicon URL that stays put.

Step 5: If only one browser or platform looks wrong

When Chrome shows your icon but Safari does not (or the reverse), suspect format support rather than your server. Safari only supports SVG favicons from version 26 (September 2025), so on Safari 18 and earlier a site that declares only an SVG will fall back — or show nothing — there; keep the PNG and ICO declarations alongside it. Conversely, a browser that prefers SVG may ignore a broken SVG file even when a perfectly good PNG is also declared, so validate the SVG rather than assuming the fallback will save you.

Home-screen icons are a separate system again. iOS uses only the 180×180 Apple touch icon and applies its own rounded mask; Android Chrome reads the icons in your web app manifest and crops them to the launcher’s shape. If tabs look right but the home screen does not, debug the touch icon and manifest, not the tab icon — a missing site.webmanifest, wrong icon sizes inside it, or a transparent touch icon are the standard culprits.

Step 6: If Google Search still shows the old (or a generic) icon

Google is the slowest place for a favicon to update, and the one you control least: it crawls the favicon separately, stores its own copy, and refreshes it on its own schedule. Even when everything is correct, this can take several days to a few weeks, and no button forces an immediate change.

What you can do is make sure your site is eligible and easy to recrawl:

  • The favicon is declared with <link rel="icon"> on the home page, and both the home page and the favicon file are crawlable — not blocked by robots.txt, a login, or server rules.
  • The icon is a square raster image in a format Google Search supports (PNG, ICO, GIF, JPEG…; SVG is not on Google’s list), at least 8×8 pixels and ideally larger than 48×48 (96×96 is a safe choice). Google’s old multiple-of-48 rule was dropped from its documentation in 2024. Google scales the icon down for display.
  • The favicon URL is stable. If you versioned the URL to beat the browser cache, leave it alone afterwards; changing the URL repeatedly restarts Google’s clock.
  • The design is legible at very small sizes. Google reserves the right not to show a favicon that is inappropriate or misleading, but in practice the quiet reason a correct icon looks “wrong” in results is fine detail that collapses at 16 pixels.

In Google Search Console you can inspect your home page URL and request indexing to nudge a recrawl of the page. After that, patience is genuinely the remaining step: check again over the following days rather than redeploying daily, since every URL or file change can delay the refresh you are waiting for. Our FAQ covers the same ground briefly under why Google does not show your favicon.

Run one check against the live site

Once you think everything is fixed, verify the deployed site rather than your local files. The favicon checker fetches your live page, lists every icon declaration it finds, downloads and validates each file (status, format and actual size), inspects the manifest, and checks Google’s size requirements — then previews the result in browsers, Google results, iOS and Android. If it reports an error, fix that specific item and re-run it; if it is clean but your own tab still shows the old icon, you have confirmed it is local caching, and Step 4 is your answer. Still seeing the previous icon everywhere after a clean check? Your host or CDN is likely serving a cached copy of the page or the files themselves.

The five-minute checklist

  1. Open /favicon.ico and your declared icon URLs directly: they return the new image, with no 404, login page or stale copy.
  2. View the live page source: one correct set of <link> tags in the <head>, on the home page and other pages, with no competing set from a theme or plugin.
  3. Confirm real formats and sizes: SVG plus 96×96 PNG, ICO, opaque 180×180 touch icon, and 192×192/512×512 manifest icons.
  4. Test in a private window; then version the icon URLs (?v=2) and purge any CDN cache to defeat the browser cache.
  5. Run the checker on the live URL and fix anything it flags.
  6. For Google Search only: confirm the icon is square, larger than 48x48 pixels and in a format Google supports (PNG or ICO, not SVG), keep the URL stable, request indexing of the home page in Search Console — then give it days, not minutes.

Almost every “favicon not showing” report resolves into one of these: a file that is not really there, markup the browser never sees, an icon in the wrong format or size, or a cache doing exactly what it was designed to do. Find which of the four you have, fix that one thing, and the little icon will turn up — in your tab first, and in Google’s results in its own good time.

All favicon articles