Favicon Checker: Does Your Site's Icon Actually Load?

By ZeroFee Tools · October 4, 2026 · 6 min read

A missing favicon shows visitors a blank tab, a generic globe in their bookmarks and a site that feels unfinished. The cruel part is that you can deploy an icon, see it in your own browser thanks to caching, and never realize half your visitors see nothing. The free Favicon Checker from ZeroFee Tools probes any domain's two conventional icon locations, /favicon.ico and /apple-touch-icon.png, using real image loading and reports exactly what comes back, including pixel dimensions when the icon is found.

It is also honest about its limits, which matters more than it sounds. Browsers block web pages from reading other sites' HTML, so no purely client-side tool can inspect link rel="icon" tags or web-app manifests on arbitrary domains. This checker tests the two standard locations where the vast majority of sites keep their icons, and says so plainly. Pair it with the open graph preview to check how your links look when shared, and the social image checker to verify your share images, and you have covered the three visual details visitors notice before reading a word.

What does a favicon checker actually test?

This checker tests whether the two conventional icon files load: /favicon.ico, which browsers request automatically for tabs and bookmarks, and /apple-touch-icon.png, the 180x180 icon iOS uses for home-screen bookmarks. It performs a real image load with onload and onerror handlers, then reports the pixel dimensions of whatever successfully loads.

A real load test is meaningfully different from a guess. Some tools simply construct the URL and assume the file exists, or they check an HTTP status that a misconfigured server might fake. Loading the file as an image proves the bytes are actually an image the browser can render, and it surfaces the dimensions, which tells you whether that apple-touch-icon is really 180x180 or a stretched 64px afterthought.

The two locations are conventions, not requirements, and that distinction is the whole point of the tool's honest framing. The vast majority of sites keep their icons at these paths because browsers have requested /favicon.ico automatically since the early web, and Apple documented the apple-touch-icon path for iOS. If both are missing here, the site's icon either lives at a non-standard path declared in a link tag, or it genuinely does not exist.

Why can't an online tool read my site's link tags?

The browser's same-origin policy blocks a web page from fetching and reading HTML from other domains. A client-side tool can request your icon files as images, which is allowed, but it cannot download your page source to inspect link rel="icon" tags or your web-app manifest. Only the site owner, or a tool with a server backend, can inspect those.

This is a security feature, not a bug, and understanding it saves you from chasing phantom problems. If it were possible, any website you visit could silently read the pages of your bank, your email and your intranet. Image loading is exempt because rendering an image does not expose its surrounding document, which is exactly why this checker probes the files directly instead of pretending to audit your HTML.

The practical consequence is simple: treat a "not found" result as "the conventional files are missing," not as "no icon exists anywhere." If you know your icon lives at /assets/icons/favicon-32x32.png and is declared in a link tag, this tool cannot see it. The robust fix, and the one the tool's guidance recommends, is to also deploy the icon to /favicon.ico, the one location every browser checks unprompted.

What sizes and formats should a proper favicon setup include?

Ship a multi-size ICO file containing 16x16, 32x32 and 48x48 versions at /favicon.ico for tabs, bookmarks and desktop shortcuts, plus a 180x180 PNG at /apple-touch-icon.png for iOS home-screen bookmarks. That pair covers every mainstream browser and device without any link tags at all, which is exactly what this checker verifies.

The multi-size ICO is an old format doing a modern job. Browsers pick the closest size for each context: 16x16 for the tab, 32x32 for the taskbar and bookmarks bar, 48x48 for desktop shortcuts. A single-size 16px icon scaled up to a shortcut looks blurry, and a single large icon downscaled to a tab can turn to mush, so the container with three sizes is worth the small effort.

The 180x180 apple-touch-icon is the one people forget, and it shows up in an embarrassing place: a customer saves your site to their iPhone home screen and gets a tiny screenshot of your page instead of your mark. iOS also applies its own rounded-corner masking, so keep the artwork safely inside the canvas with padding. Android's manifest icons are the one piece this client-side approach cannot verify, which is worth knowing when you audit a progressive web app.

My icon exists, but the checker says not found. Why?

The most common causes are a non-standard file path declared only in a link tag, aggressive favicon caching showing you a stale miss, or a server blocking the icon from loading cross-origin. Rule out caching first with a hard refresh, then confirm the file actually loads at /favicon.ico directly; if it does not, deploy it there.

Caching deserves special attention because favicons are cached more aggressively than almost any other asset. Browsers assume the little tab icon rarely changes, so after you deploy a fix you can stare at a cached "not found" for hours and conclude the fix failed. A hard refresh, a private window or simply waiting a few minutes resolves most of these phantom failures, which is why the tool reminds you about it right next to the results.

Hotlink protection is the sneakier cause. Some servers and CDNs block cross-site image requests, which breaks a client-side probe even though the icon loads fine for direct visitors. If the direct link the tool provides opens the icon in a new tab but the probe reports a failure, your server is likely blocking the referer-based request. Either way, the fix is the same boring, reliable one: put a proper multi-size icon at /favicon.ico and the problem disappears for every browser, bookmark and checker at once.

How to use the Favicon Checker in 4 steps

1. Enter any domain. Type the domain or full host you want to check, such as example.com or shop.example.com for a subdomain.
2. Run the check. The tool probes /favicon.ico and /apple-touch-icon.png on that host with real image loading, all from your browser.
3. Read the file-by-file results. Each location shows found or not found, with pixel dimensions when an icon loads and a direct link to open each file yourself.
4. Fix what is missing. Deploy a multi-size ICO to /favicon.ico and a 180x180 PNG to /apple-touch-icon.png, then hard-refresh and re-check to rule out caching.

6 practical favicon tips

• Always deploy to /favicon.ico. Link tags are fine as a supplement, but the root ICO is the one location every browser, bookmarklet and checker requests without being told.
• Design at 16px, not just 64px. Your detailed logo will be illegible as a tab icon. Simplify ruthlessly: one letter, one shape, one bold color, tested at actual tab size.
• Use hard refresh when verifying. Favicons cache aggressively. Verify a new icon in a private window or after a hard refresh so a stale miss does not send you debugging a fixed problem.
• Do not forget the iOS icon. A 180x180 apple-touch-icon.png with safe padding turns a home-screen bookmark from an ugly page screenshot into your actual mark.
• Check subdomains separately. Shop, blog and app subdomains often run different themes or deployments, and each host needs its own icons. Enter the full host to probe it directly.
• Re-check after redesigns and migrations. Theme changes, CDN moves and platform migrations silently drop icon files. A thirty-second check after every launch catches it before customers do.

Frequently asked questions