How to Fix the Annoying 404 favicon.ico Not Found Error

May 31, 2026 · 4 min read

You open your browser console on a fresh HTML page and see it immediately: Failed to load resource: the server responded with a status of 404 (Not Found) — favicon.ico. You didn’t reference any favicon. You didn’t ask for one. Yet there it is, cluttering your logs every single time.

Here’s what’s actually happening and how to fix it properly.

Key Takeaways

Browsers, crawlers, and monitoring tools automatically request /favicon.ico from your site root, even without an HTML reference.
The 404 error is harmless but pollutes server logs and obscures real issues.
The most reliable fix is placing an actual favicon.ico file at your site root.
Modern setups should also declare SVG, PNG, and Apple Touch Icon variants via <link rel="icon"> in the HTML <head>.
Frameworks like Next.js handle favicon placement through file conventions, but the root-level request requirement remains the same.

Why Browsers Request favicon.ico Without Being Asked

Browsers don’t wait for your HTML to tell them where the favicon is. Per the WHATWG HTML Standard, when a page has no explicit <link rel="icon"> tag, browsers automatically send a GET request to /favicon.ico at the site root. This is implicit favicon discovery — built-in browser behavior, not a bug in your code.

It’s not just browsers, either. RSS readers, Slack link previews, search engine crawlers, and uptime monitoring tools all make the same automatic request. So even if your browser respects a <link rel="icon"> tag, other clients may still hit /favicon.ico directly.

The error is harmless but noisy. It won’t break your site, but it pollutes server logs, muddies monitoring dashboards, and makes it harder to spot real errors.

The Proper Fix: Serve a Real favicon.ico at the Site Root

The most reliable solution is to place an actual favicon.ico file at your site root so the automatic request returns a 200 instead of a 404.

You can generate one at favicon.io or realfavicongenerator.net. Drop the file here:

/favicon.ico   ← browsers and crawlers request this automatically

This works regardless of what other favicon declarations you have in your HTML.

Modern Favicon Setup: The Complete HTML Declaration

Once you have your root favicon.ico covered, add explicit declarations in your <head> for modern browsers. The MDN Web Docs on rel=“icon” recommend using rel="icon" rather than the outdated rel="shortcut icon".

<!-- The /favicon.ico file at your site root is served automatically — no HTML tag required -->

<!-- PNG favicon --> 
<link rel="icon" type="image/png" sizes="32x32" href="/favicon.png"> 

<!-- SVG favicon for browsers that support it -->
<link rel="icon" type="image/svg+xml" href="/favicon.svg">

<!-- Apple Touch Icon for iOS home screen bookmarks -->
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

<!-- Web App Manifest for installable PWAs -->
<link rel="manifest" href="/manifest.webmanifest">

A few things worth noting here:

SVG favicons scale perfectly at any size and support dark mode via CSS prefers-color-scheme inside the SVG itself.
Apple Touch Icon is specifically for iOS when a user saves your site to their home screen. It’s separate from your favicon and is typically a 180x180 PNG.
Web App Manifest icons serve a different purpose — they define icons for installed PWAs. They do not replace your favicon and won’t prevent the /favicon.ico 404.

What About Frameworks?

Framework-specific tooling handles some of this automatically. For example, the Next.js App Router treats a favicon.ico file placed in the app/ directory as a special file convention and generates the correct metadata automatically. Other frameworks have similar conventions. Check your framework’s documentation. Regardless of how the favicon is configured, it’s still a good idea to ensure requests to /favicon.ico are handled, since browsers, crawlers, and other clients may request that path directly.

Quick Diagnostic: Check Your Browser DevTools

Open the Network tab in DevTools, reload the page, and filter by favicon. If you see a 404 for favicon.ico, your root file is missing or not being served correctly. A 200 response means you’re done.

Conclusion

Place a real favicon.ico at your site root — that single file stops the automatic 404 from browsers, crawlers, and monitoring tools alike. Then add explicit <link rel="icon"> declarations for your SVG favicon, PNG fallback, and Apple Touch Icon to give modern browsers the best available format. Clean logs, proper icons, no hacks required.

FAQs

You can filter it out of your console, but the underlying request still hits your server and shows up in logs, analytics, and monitoring tools. Serving an actual favicon.ico file is a one-time fix that solves the problem at its source rather than hiding it. It's also far less work than configuring filters across multiple tools.

Yes. Many clients including older crawlers, RSS readers, and link preview bots ignore HTML link tags and request /favicon.ico directly from the site root. Without a file there, those requests return 404. Serving both a root favicon.ico and modern link declarations covers every client reliably.

A multi-resolution ICO file containing 16x16, 32x32, and 48x48 pixel versions covers nearly every use case. Most favicon generators produce this automatically. If you only need a single size, 32x32 is the safest default since it works well in browser tabs and bookmark bars across all major platforms.

Browsers cache favicons aggressively, sometimes for days. Try a hard refresh, clear your browser cache, or test in a private window. Also verify that the file is actually being served from the site root and returns a successful response. If it loads there, the 404 should clear once the cache expires.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.