You updated your favicon, deployed the new files, and reloaded the page — but the browser still shows the wrong icon. Maybe it's an old logo from six months ago, a different site's icon, or a blurry generic placeholder that shouldn't be there at all.

This is one of the most common favicon frustrations developers hit. The files exist on the server. The HTML tags look correct. Yet the browser chooses wrong favicon assets and ignores what you actually deployed.

Here's the quick fix first, followed by the real reasons it happens.

The 2-Minute Quick Fix

Most "wrong favicon" symptoms come down to a single root cause: browser precedence. When multiple icon sources exist, browsers follow a strict lookup order — and any conflict hijacks the result.

Run this checklist first:

  1. Delete any /favicon.ico at your site root. It overrides HTML declarations in many browsers.
  2. Add explicit rel="icon" tags in your <head> with proper sizes and type attributes.
  3. Append a cache-busting query string (e.g., ?v=2) to force the browser to fetch the new file.
  4. Hard reload with Ctrl+Shift+R, or walk through our favicon cache clear guide for stubborn cases.

If that solves it, you're done. If not, the browser is choosing wrong favicon files because of a precedence conflict — and the deeper diagnosis starts now.

Why Browsers Pick the Wrong Icon

Browsers don't blindly trust your HTML. They run a lookup sequence defined by the HTML specification, and any mismatch can hijack the result.

1. The /favicon.ico Trap

If a legacy favicon.ico lives at your site root and you ship modern <link rel="icon"> tags in your HTML, browsers will often prefer the ico file. Many browsers automatically request /favicon.ico when no other icon is declared, and they treat that file as authoritative once it exists.

The fix: delete the root favicon.ico, or serve it explicitly through a link tag with a precise sizes attribute so the browser knows what it is.

2. Missing or Wrong sizes Attribute

The sizes attribute tells the browser what resolution each icon file contains. Without it, the browser may upscale a 16x16 PNG to display in a 32x32 context — giving you that pixelated look everyone hates.

Always declare it explicitly:

<link rel='icon' type='image/png' sizes='32x32' href='/icons/favicon-32x32.png'>
<link rel='icon' type='image/png' sizes='16x16' href='/icons/favicon-16x16.png'>

The HTML spec defines rel="icon" as the standard way to declare site icons. See the WHATWG HTML Living Standard for the exact parsing rules.

3. Conflicting type Attributes

If you declare type="image/svg+xml" but the served file is actually a PNG (or vice versa), browsers may skip the file entirely and fall back to whatever else is available — including a cached old version.

Verify your MIME types match reality. A common bug: a CDN serves image/png even when the file extension and HTML attribute claim SVG.

4. Web App Manifest Override

When your site has a site.webmanifest with its own icons array, browsers may prefer the manifest's icons over your HTML link tags — especially on mobile and for "Add to Home Screen" flows.

Check /site.webmanifest and make sure the icons array points to the same files your HTML declares. Mismatched sizes or formats will make the browser choose wrong favicon assets based on platform-specific logic.

5. CDN and Edge Cache Lag

Cloudflare, Fastly, and similar CDNs aggressively cache static assets. Even after you deploy, edge nodes may keep serving the old favicon for hours or days.

Purge your CDN's cache for /favicon.ico, /icons/*, and /site.webmanifest paths after every deployment — otherwise the browser chooses wrong favicon files purely because of stale edges.

6. Service Worker Traps

Service workers can cache favicon responses independently of the browser's HTTP cache. If your PWA caches the icon on first install, users keep seeing the old version until the service worker updates.

Bump your service worker version and use a cache-busting query string in the href value. A versioned filename is even safer.

Prevention: Build a Bulletproof Icon Stack

Once you've fixed the immediate issue, harden your setup to prevent future "wrong favicon" incidents:

Wrap-Up

When the browser chooses wrong favicon files, it's almost never random. It's following a precedence order you didn't account for, fetching from a cache you forgot to invalidate, or reading a type attribute that doesn't match the served file.

Strip out the root favicon.ico, declare explicit link tags with correct sizes and types, keep your manifest in sync, and purge caches on every deploy. That sequence resolves most "wrong favicon" cases — and the remaining edge cases usually point to a CDN or service worker trap you can debug with DevTools in a few minutes.