Favicon Checker

See which site icons a page declares, and which parts of the recommended set its markup never mentions.

Secure server processingWeb & SEOWorkingNo account needed

What this tool does

Favicon Checker hands the address you enter to the OmniKitly processing service, which requests that one page and scans the HTML it gets back for link elements whose rel attribute contains icon or manifest. The report opens with a table of the matches — rel, href, sizes and type, each written out as the markup had them. Under it sits a six-row scorecard answering yes or no for /favicon.ico, a 32×32 PNG or an SVG, an SVG icon on its own, a 180×180 Apple touch icon, a web app manifest link and a theme-color meta tag. Warnings name the gaps that change what a browser draws, notes cover the softer advice, and the raw fetch stays downloadable as favicons.json, which is also the only place the address the request finally settled on is written down.

An icon set is easy to get half right. The tab icon comes from one link, the iOS home screen from another, and the two are usually added months apart by different people, so a redesign that replaces the 32-pixel PNG routinely leaves an Apple touch icon pointing at a path that no longer exists. Seeing all the declarations in one list is how you notice that a head element promises four files while the theme ships three, or that one href still names a directory the build moved.

What comes back is the page's claim, not the file behind it. No icon URL is ever requested, so an href that answers 404, an Apple touch icon declared as 180×180 that is really 57 pixels square, and an .ico holding one blurry frame all appear in the table looking healthy. The sizes column is an attribute somebody typed, never a measurement, and even the scorecard row reading /favicon.ico at the root is answered from a declared link rather than by asking the root for that file. The status of the page fetch is not reported either, so a mistyped address that lands on a styled 404 comes back scanned like any other page — an empty list can mean the markup declares nothing or that you never reached the page you meant.

The check runs on the service because a page on another domain cannot be read from this tab. Your URL travels there over an encrypted connection as a job setting, the fetch reads at most 512 KB of the response and follows at most five redirect hops, and the stored job row and its report are swept away together once the retention window closes, six hours after the run by default. Only public http and https addresses are accepted: loopback, private ranges, URLs carrying a username and password, and hostnames ending .local, .internal, .lan or .home are refused, and every address the hostname resolves to is checked before a socket is opened.

How to use it

  1. Enter the page address. A full http:// or https:// URL, and nothing else — the box takes an address to fetch, not markup. The home page is usually the right one to test, since most sites declare their icons in a single shared layout, and it has to be reachable from the public internet.
  2. Run it and read the two tables. The first lists every matching link as the markup wrote it. The second answers yes or no for each of the six assets in the recommended set, with the warnings and notes printed underneath.
  3. Work through the warnings before the notes. A missing 32×32 or SVG icon, an absent Apple touch icon and a link element with no href at all are the findings that change what a browser or an iPhone actually draws. The lines below them are suggestions, not faults.
  4. Keep favicons.json if you will check again. The fetched JSON downloads as a file, which turns a post-deploy re-run into a diff against the previous one rather than a memory test.

Processing & privacy

Secure server processing. This operation requires temporary server processing.

Common use cases

A browser tab showing the wrong icon

The list says whether the page declares an icon at all, and whether the href still names the path the file was deployed to after a rebuild.

An iOS home screen shortcut looking wrong

Adding a page to the iOS home screen uses the Apple touch icon. If no such link appears in the report, iOS has nothing to draw and falls back to a thumbnail of the page.

Taking over a site somebody else built

One list of declarations is quicker than reading an unfamiliar head element line by line, and it names every icon path the site depends on.

After a CMS or framework upgrade

Templates rewrite the head between versions. Running this against the deployed page shows what the server sends now, not what the source template looks like it should send.

Questions

Is my page uploaded anywhere?
There is no file in this job — the input is an address. It travels to the OmniKitly processing service over an encrypted connection as a job setting, the service fetches the page from its own IP address, and the JSON report and the job record are removed together six hours after the run by default.
Does it confirm the icon files actually exist?
No. Only the page's HTML is fetched; the icons it points at are never requested. A dead path and a working one are indistinguishable in the report, so treat it as a list of what the markup promises and open a suspect href yourself to see what is there.
Does it read the web app manifest?
The link element is matched and listed, and the scorecard has a row for it, but the manifest file itself is never fetched. The 192 and 512 pixel icons an Android install prompt uses live inside that file, so a yes on that row means the link is declared, not that the icons behind it exist — open site.webmanifest to check those.
Can I paste the page's HTML instead?
No, even though the input box invites it. Everything typed there is sent to the service as the address to fetch, so pasted markup — including the head element the Load sample button fills in — comes back refused as an invalid URL. That label and that button are leftovers from an in-browser version of the same check, and the page has to be published somewhere the service can reach before it can be tested.
What does the Site URL setting do?
It sets the base address that relative icon paths are measured against. Very little changes in the report: hrefs are always printed the way the page wrote them, and the only visible consequence is whether an icon that resolves to an http:// address gets flagged as insecure. A run on the service already uses the address the fetch settled on as that base, so the box can stay empty.
My icons are added by JavaScript, so why is the list empty?
The page is fetched and read as text with nothing executed. Links a script inserts after load are invisible here — and to most crawlers and link-preview bots, which do the same thing. Because the scan is a pattern over the response text rather than a parser, an attribute written without quotes is missed too, though quoting is close to universal.
How long does it wait for a slow site?
Each request is given fifteen seconds, and a single run can make six of them: the page itself plus up to five redirect hops. A chain of slow redirects therefore keeps going well past any one of those timeouts, and nothing caps the run as a whole. There is no retry control; running it again is the only option.

Related tools