avicon

Checker

See what any live site serves to tabs

Type any domain and see exactly which icons it declares to browsers, phones and search engines — graded, previewed, and checked for reachability.

Try:

Scans the live HTML

Reads the actual <link> and <meta> tags a browser sees.

Grades coverage

From classic favicon to Apple touch icons and the web manifest.

Previews the result

See the real icon in tabs, on phones, and in search.

What the checker actually looks at

Seven checks, each mapped to a real place a favicon shows up — not just whether a file happens to exist.

Classic favicon

A <link rel="icon"> (or the /favicon.ico fallback) that actually resolves — this is what every browser tab uses.

Scalable SVG icon

An SVG favicon stays crisp at any resolution and on any pixel density, instead of one raster size stretched or squeezed.

Apple touch icon

iOS ignores favicon.ico entirely — without this tag, saving the site to an iPhone home screen falls back to a screenshot.

Web app manifest

Android and installable PWAs read their icon set from site.webmanifest, not from <link> tags.

High-res icon (≥180px)

A large source icon keeps home-screen shortcuts and app switchers sharp on high-DPI screens.

theme-color set

Tints the mobile browser's address bar and status bar to match the brand instead of showing the OS default.

All icons load

Every declared icon actually returns a successful response — a broken link here is a console error visitors don't see, but crawlers do.

How the A–F grade works

The score is simply the share of the seven checks above that pass, banded into a letter grade.

GradeScoreWhat it means
A90–100Full modern coverage: classic, SVG, Apple, manifest and theme-color, all reachable.
B75–89Solid coverage with one minor gap — usually a missing SVG or theme-color.
C55–74The basics work, but mobile or PWA icons are likely missing or broken.
D35–54Only a bare favicon.ico is reliably served — most surfaces show no icon at all.
F0–34No working icon found, or every declared icon fails to load.

Checker FAQ

It fetches the page's public HTML the same way a browser would — reading <link> and <meta> tags, following a declared web manifest, and probing each icon URL to confirm it loads. It doesn't render JavaScript, so icons injected purely client-side after page load won't be picked up.

Yes — it only reads what's already public. There's no login, no crawling beyond the one page you point it at, and nothing about the check is stored afterward.

Your browser may be showing a cached icon from a previous visit, or the icon might be set via JavaScript after the page loads rather than in the initial HTML. Do a hard refresh and re-run the check, and compare the reported <link> tags against what's actually in your page source.

A or B covers everything that matters in practice: a working tab icon, an Apple touch icon, and manifest icons for Android/PWA installs. Chasing 100 mainly means adding an SVG favicon and a theme-color meta tag on top of that.

No — Checker only diagnoses what a live site currently serves. If it flags gaps, use the Generator to build a set from scratch or the Converter to turn an existing logo into the missing sizes, then re-run the check.

No — the checker only reaches publicly accessible URLs, the same as any outside visitor or crawler would. Internal, local and private-network addresses are deliberately blocked rather than fetched.

No — it's scoped specifically to icons: the classic favicon, Apple touch icon, manifest icons, and theme-color. It doesn't audit meta descriptions, headings, page speed or the rest of on-page SEO.

There's no login or quota for normal, one-at-a-time use. What isn't allowed is scripting the checker to send high-volume automated traffic — see the Terms of Service for the full acceptable-use policy.