Site icons present, missing, or misconfigured — one URL reports the truth
Paste a URL. Siteicons reads the page's <head>, collects every icon declaration, requests each one, and reports what came back: present with real pixel dimensions, present but the wrong format, or missing entirely. It also checks the two conventional paths — /favicon.ico and /apple-touch-icon.png — that browsers request without being told.
How it works
Extract declarations
Siteicons fetches the page and parses every <link> tag with rel="icon", "shortcut icon", "apple-touch-icon" — including sizes and type attributes.
Request each icon
Every declared URL is fetched individually, plus the two root fallbacks browsers request by convention. HTTP status, Content-Type, and real pixel dimensions are recorded for each.
Compare to what clients need
The output maps each icon to the clients that would use it: a browser tab, a Google Search result, and an iOS home-screen bookmark. You see which has nothing to use.
What it reports
- Every declared icon with its declared type and sizes
- HTTP status code for each icon URL
- Real pixel dimensions read from the binary header (ICO, PNG, JPEG, GIF, WEBP, SVG)
- Automatic check of
/favicon.icoand/apple-touch-icon.pngat the domain root - A three-way verdict: what a browser tab, Google Search, and iOS bookmark each have to use
Known limitations
- Cannot reach sites hosted on Cloudflare's own network — those will report as unreachable rather than closed
- Only checks HTTP and HTTPS URLs
- Dimension parsing depends on correct Content-Type headers; magic-byte sniffing is attempted as fallback