Favicon Showing a 404 in the Console: How to Fix It
That harmless-looking favicon.ico 404 in your console isn't actually harmless — here's how to clear it for good.
· 4 min read
Quick answer: browsers automatically request /favicon.ico at your domain root on every single page load, regardless of what your <link> tags say — so if that exact file doesn't exist there, you get a 404 logged on every visit even if a different icon is displaying just fine elsewhere on the page.
Open devtools on a lot of sites and you'll spot the same thing in the network tab: a quiet GET /favicon.ico 404. The page looks completely normal, the tab icon is showing, and yet there it is on every single load. This isn't a glitch — it's a browser convention that most sites accidentally leave unfulfilled.
Why this request happens even when you never asked for it
Browsers request /favicon.ico as a fallback convention that predates the <link rel="icon"> tag entirely. It doesn't matter if your <head> declares a perfectly valid icon at /assets/icons/app-icon.png — the browser still separately checks for /favicon.ico at the root, because that's the historical default location, and some contexts (older tools, certain crawlers, some browser chrome) rely on it existing there regardless of what else is declared.
So you can have a fully correct, fully working favicon setup via <link> tags, and still generate a 404 on every page load, because the two systems are independent. One doesn't satisfy the other.
Why it's worth fixing even though the page "looks fine"
It's easy to dismiss this as cosmetic since visitors never see it. A few reasons it's still worth clearing:
- Noisy logs. Every page load writes a 404 to your server logs. On a busy site that's a meaningful amount of log noise for a non-error, which makes real errors harder to spot when you're scanning logs for problems.
- Wasted requests. Small individually, but it's still an extra round trip on every single page view across your entire traffic, for a resource that should be a simple cache hit.
- Looks unprofessional in devtools. Any developer, auditor, or technically curious user who opens the network tab sees a 404 on your production site. It's a small thing, but it reads as sloppy.
- Some tools specifically check for it. Certain crawlers, SEO auditing tools, and automated site-quality checks look for
/favicon.icodirectly and flag its absence as an issue, separate from whatever your<link>tags declare.
The fix
Place a real favicon.ico file at the actual root of your domain — https://yoursite.com/favicon.ico — not inside a subfolder like /assets/favicon.ico or /static/icons/favicon.ico. The fallback request is always for /favicon.ico specifically; it does not follow redirects to wherever your other icons live, and it does not check subdirectories.
If you already have a full icon set built with correctly sized PNGs and a manifest, you likely already have everything you need — you just need one of those files, packaged as a multi-resolution .ico, sitting at the root path. Our favicon size guide covers what that file should contain.
Single-page apps and static hosts need explicit root serving
This is where the 404 shows up most often in practice. Single-page app frameworks and some static hosting setups serve everything from a public or dist folder, but if that folder's contents aren't mapped to serve directly from the domain root, a file placed at public/favicon.ico can still end up reachable only at some other path, or not reachable at all if the build process doesn't copy it forward. Check your host's static file serving rules specifically for whether root-level files in your public folder are actually exposed at the domain root, not nested under a build output path.
Why this convention still exists in 2026
It might seem strange that browsers still bother with a fallback request for a file format from the 1990s. The short answer is backward compatibility — see our guide on whether favicon.ico is still needed for the full case on why this old convention has stuck around and why it's still worth shipping the file rather than fighting the convention.
Confirm it's actually fixed
After deploying a favicon.ico to the root, don't just trust that the 404 is gone — verify it. Run the domain through the favicon checker to confirm /favicon.ico resolves with a real image response, separately from whatever your <link> tags declare. It's a fast way to confirm the fix landed everywhere the fallback request actually fires, rather than just on the one page you happened to test.
◎ Try the Checker
Point it at a URL and get a graded report of every icon a site declares — plus how each one looks on real devices.
Open Checker