Favicon checker

A favicon checker needs the page, its manifest and the real files

A screenshot of a browser tab proves only that one browser displayed something at one time. It does not identify the declaration that won, expose the linked web manifest or show whether a 16 pixel ICO entry sits beside larger artwork. This checker starts from the current document’s icon links and then inspects the bytes that those declarations identify.

The bookmarklet runs in the exact page you opened. It records regular favicon links, Apple Touch Icon and mask links, Microsoft tile metadata and icons from the linked manifest. It preserves declared type, sizes, purpose, color and media. The conventional root /favicon.ico is only a fallback when no normal rel="icon" appears; a guessed filename is never presented as a declaration.

Browser favicon checks separate declarations from decoded evidence

The HTML standard describes the icon link type and its selection hints. A sizes token and a MIME type are author-provided metadata, not a decoded measurement. This report sniffs each supported file signature, decodes actual dimensions and compares explicit claims with the returned bytes. Missing optional hints are not invented as failures, while contradictions remain visible.

ICO files receive their own directory check. A single file can contain 16, 32, 48 and 256 pixel entries, so reporting only the largest preview would hide useful small-icon evidence. Byte-identical files are grouped with SHA-256, but every source URL and declaration stays in the report. If your task is to save the files rather than diagnose them, use the favicon downloader with its selectable ZIP and receipts.

The Google Search favicon check begins at the hostname root

Google’s current favicon documentation for organic results says that the link belongs on the hostname home page, that the file must be square and at least 8×8 pixels, and that an icon larger than 48×48 is recommended for clarity across surfaces. Google supports one favicon per hostname, so a collection from /news/article cannot establish what the root page declares. The Search score is deliberately withheld in that case instead of grading the wrong document.

A browser bookmarklet cannot become Googlebot. It cannot prove crawler permission, robots handling, URL stability over time, cache state, recrawl timing, visual brand suitability or Google’s eventual selection. Those limits appear inside the exported report. A clean byte check is useful implementation evidence, not a promise that a search result will show the icon.

Apple Home Screen is a separate icon surface

Apple’s archived Safari web-content guide documents a separate Apple Touch Icon relation, PNG artwork and a 180×180 iPhone Retina example. The Apple card therefore checks that declaration, readable PNG bytes, square geometry and 180 pixel coverage. A regular tab icon is not silently credited as a dedicated Home Screen asset.

These checks still cannot judge composition. A technically square logo may have illegible detail or unsafe edge content. Test the result on the devices your audience uses. A low Apple score can also be an intentional product decision when Add to Home Screen is outside the site’s scope; it is never folded into a universal total.

Web app manifest icons keep purpose and size as distinct evidence

The W3C Web App Manifest model gives each icon its own source, type, sizes and purpose. General-purpose and maskable icons are not interchangeable. The installed-app card checks for decoded square general-purpose coverage at 192 and 512 pixels and a dedicated 512 pixel maskable source. These are coverage checks, not a complete installability audit.

Maskable artwork has a visual constraint that file metadata cannot prove. The standardized safe zone keeps important content inside a centered circle; web.dev’s maskable icon guide recommends testing it in browser DevTools. This report can confirm purpose="maskable", decoded square geometry and size, but it leaves safe-zone quality explicitly unverified.

The favicon checker exports the same rules you can inspect on screen

Browser declarations, Google Search, Apple Home Screen and installed web apps receive separate scorecards. Every rule has a stable ID, status, evidence, owner, action and verification step. CSV is shaped for a backlog; JSON retains the whole report, page provenance, manifest status, summaries and boundaries. There is no hidden AI judgment and no combined score that pretends all four surfaces are mandatory.

Run the collector again after a change rather than treating an old export as live state. The transfer is origin-bound and bounded; direct fallback reads are credential-free, and for an imported file they happen only after you confirm them. If you instead need to create a new multi-entry classic icon, the PNG to ICO converter is the narrow generation route. The favicon generator creates the complete browser, Apple and installed-app package when the whole icon set needs replacement, and if the logo it should start from is only published inside the page, the website image extractor collects that artwork from the same open tab.

Collection happens in the page you opened and analysis happens in this tab, so the evidence and the exported report are never sent to CreatorValet. Any icon reads you see are requests to the site being checked, and the guide to checking local processing shows how to tell those apart in your browser’s Network panel.