favicon checker
Your site already has
icons. Are they right?
Enter an address and this reads the page the way a browser does, then fetches the manifest and the icon files it declares: which are there, which are missing, and which are declared but do not load. Where one file would fix a problem, the report names it and offers to generate it.
This tool works differently from the generator. The generator never uploads your image — it runs in your browser. The checker cannot: it fetches the public address you type, from our server, and reads that page’s HTML, then the files it declares — the web manifest, and the icon files themselves, which are fetched so they can be measured and drawn back into the report. Only the address you enter is sent. The addresses you check are then kept in this browser, so it can tell you what changed since last time; they go nowhere, and you can clear them.
Questions
Why does a check say unknown instead of pass or fail?
Because nobody looked, and that is not the same as nothing being wrong. A file that did not answer, or one the head declared that the check never fetched, leaves a real question open. Those are reported as unknown and counted separately rather than folded into the failures or covered by a green tick, so the score never quietly includes something that was not measured.
Where does the check actually run?
On our server, not in your browser. It fetches the page’s HTML and the icon files the head declares, and carries the images back so the previews can be shown. The report says so above the results, and names the user-agent that was sent so you can match it against your own logs.
The icons look right in my browser. Why does the report disagree?
Most often because your browser has them cached and this does not. Every file is asked for fresh, once, from one network, and a server can refuse a request that is not a browser. The report names the exact address it asked for — open that address yourself before changing anything.