Paste a URL and find out whether your favicon actually works. We fetch every icon the page declares and read the real file, not just the HTML.
Free, no login, no email. Nothing stored beyond a 24 hour cache. Markdown copy · API and MCP
Paste any URL
We fetch the page the way a browser would and read every icon declaration out of its head: rel=icon, apple-touch-icon, mask-icon, and the web app manifest.
We fetch every icon
Each declared icon, the manifest, and the implicit /favicon.ico are fetched for real. We read the format and the pixel dimensions from the file's own header rather than trusting the HTML or the content type.
Read what is broken
You get a yes or no on whether a browser gets an icon at all, then a check per problem with the exact fix. Copy the raw JSON if you want the result in a script.
A favicon has a declaration and it has a file, and the two fail independently. Almost every tool that claims to check favicons looks at the declaration: it fetches the page, finds a link tag with rel=icon, and reports a pass. That test is satisfied by markup alone, which means it passes on a very large number of sites whose tabs are blank, because the file the declaration points at was never deployed, was deleted in a redesign, or was never at that path to begin with. The declaration is the part that is easy to get right and the part that keeps working after the file stops.
So this tool does the boring thing instead. It reads the declarations, and then it fetches each one, along with the web app manifest and the implicit /favicon.ico that browsers try when nothing is declared. Every claim on the result page is about a file we actually pulled down and looked at.
Fetching is not sufficient either, and the reason is the most common favicon failure in modern web apps. A single-page app typically has a catch-all route that returns the app shell for any path the router does not recognise. When the icon file is missing, a request for /favicon.ico therefore does not 404. It returns HTTP 200 with a complete HTML document, and depending on the host it may even carry an image content type. A checker that reads the status code sees 200 and reports success. A checker that reads the content type sees image/x-icon and reports success. The browser reads the bytes, finds a doctype where it expected an icon header, and shows the blank page glyph.
The only source that cannot be wrong about what a file is, is the file. So we identify the format from the first bytes of every response: the PNG signature, the ICO directory header, the SVG root element, the doctype of an HTML page in a costume. The same bytes give us the real pixel dimensions, out of the PNG IHDR chunk and out of the ICO directory, which is how we can tell you that the link declaring sizes="180x180" is pointing at a 57x57 file that iOS has been upscaling for two years.
A favicon is a rounding error in a site's design budget and it appears in every tab, every bookmark, every history entry, every browser's new tab grid, and every home screen somebody saves the site to. It is the only piece of your brand that is on screen while somebody is reading something else. A missing one does not break anything, which is exactly why it survives so long: nothing fails, no error is logged, no test goes red, and the generic page glyph sits next to your competitors' logos for months. It usually gets found by accident, by somebody who happened to look at their own tab bar.
That pattern is worth noticing, because the favicon is not the only thing shaped like it. The failures that survive longest are the ones with no failure signal: the Open Graph image that stopped resolving, the icon that returns HTML, the meta description that got truncated in a template change. Nobody is watching, so nobody knows.
Almost always one of three things, and this tool tells you which. The file was never deployed, so the path 404s on production only. The path is right in development because a dev server serves the whole public directory and the production host does not. Or your app has a catch-all route that answers every unmatched path with the app shell, so /favicon.ico returns HTTP 200 with an HTML page. That third one is the nastiest, because every checker that only reads the status code calls it a pass.
The same run this page does, as an HTTP endpoint and as the MCP tool check_favicon. No account, no API key. Full reference.
curl -sS https://usesuperflow.ai/api/tools/favicon-checker \
-H 'Content-Type: application/json' \
-d '{"url":"example.com"}'Returns { hasWorkingFavicon, tabIcon, icons[] with format, dimensions, bytes and problem, manifest, themeColor, checks[] with id, status and fix, counts }. 60 runs per hour per IP. Allow up to 30 seconds.
claude mcp add --transport http superflow https://usesuperflow.ai/api/mcpThen ask your agent for check_favicon. Setup for Claude Desktop, Cursor and VS Code is on the reference page.
No login, no email, no ads. Same as this one.
Superflow agents check every page of every site you ship, on every change, against your own QA rules. They tell you when something breaks, changes, or quietly disappears, including the details nobody thinks to look at twice.