Favicon Not Updating? How to Bust the Browser Cache

Quick answer: hard refresh first, then check a private window to confirm the new icon really is live — but the only fix that reliably sticks for every visitor is changing the icon's URL itself, either by renaming the file or appending a version query string like /favicon.ico?v=2.

Of all the assets on a page, favicons are cached the most stubbornly. You can replace the file on your server, confirm the deploy succeeded, and still see the old icon in your browser tab for days. This isn't a bug — it's how browsers have always treated favicons, and once you understand why, the fix is straightforward.

Why favicons cache so aggressively

Browsers historically treat favicons as a special case: a small, low-priority resource that's fetched once and kept around, sometimes with caching behavior that doesn't follow the same Cache-Control rules applied to the rest of your page. On top of that, favicons are often cached per browser profile rather than per tab or per site visit, which is why closing and reopening the tab doesn't help — the browser isn't refetching, it's reusing what it already stored for that domain across your entire browsing session.

The practical effect is that a favicon update can be "live" on your server and still invisible to returning visitors for a long time, simply because nothing forced their browser to ask again.

Fixes, in order of effort

1. Hard refresh

Cmd+Shift+R on Mac, Ctrl+Shift+R on Windows/Linux. This forces the current page to bypass cache for its main resources, and it's worth trying first because it's free and instant. It doesn't always catch the favicon specifically, since some browsers still hold onto icons separately from the rest of the page cache, but it's the first thing to rule out.

2. Open a private/incognito window

This is the real diagnostic step. A private window starts with no cached favicon for that domain, so if the new icon shows up there, your server-side change is correct and the issue is purely local caching on your regular browser profile — not a deployment problem. If the old icon still shows up in private mode too, go back to the full list of favicon-not-showing causes, because the problem is elsewhere.

3. Clear cached images and files in browser settings

Most browsers let you clear cached images and files specifically, without wiping cookies, passwords, or history. This forces a refetch of the favicon (and everything else cached) the next time you visit. It works, but it only fixes it for your own browser — every other visitor with a cached copy is still seeing the old one.

4. Cache-bust with a new URL (the permanent fix)

Browsers only decide to refetch when the URL changes. Appending a version query string is the simplest way to do that without touching any file paths elsewhere:

<link rel="icon" href="/favicon.ico?v=2" type="image/x-icon">

Bump the v value every time you change the icon going forward. Alternatively, rename the file outright — favicon-v2.png instead of favicon.png — and update the <link> tag to match. Either approach guarantees every visitor, not just you, gets the new icon on their very next page load, because as far as their browser is concerned it's a completely new resource with no cache history.

This is also the approach worth baking into your deploy process if you expect to update your favicon more than once — for example after a rebrand — so you're not troubleshooting this same issue again next time.

Bookmarked pages are a separate, harder case

Some browsers cache the favicon associated with a bookmark independently of the page's normal favicon cache, and that copy can persist even longer since it's tied to the bookmark entry itself rather than to regular browsing history. There's no reliable way to force this one — it typically requires the user to remove and re-add the bookmark. It's rare enough not to worry about unless you're hearing specifically from users who bookmarked your site.

CDNs add another layer on top

If your site sits behind a CDN, there's caching happening at the edge in addition to caching in the visitor's browser. Even after cache-busting the URL, an old CDN-cached response at that exact same path could still be served until it expires or is purged. That's a distinct problem from browser caching — see cause six in the favicon-not-showing-up guide for how to handle it.

Once you've deployed the fix, the fastest way to confirm what's actually being served right now — independent of your own browser's cache — is to run the URL through the favicon checker, which fetches it fresh rather than relying on whatever your browser already has stored.