Which of your site icons actually exist, and which are missing?
Paste a URL. Faviview reads the page's <head>, collects every icon it declares — favicon.ico, apple-touch-icon, every <link rel="icon"> — then requests each one and reports what came back. Present and the real pixel dimensions. Present but the wrong format for what it claims. Missing entirely. It also checks the two locations that clients request without being declared: /favicon.ico and /apple-touch-icon.png at the site root.
What Faviview tells you
Declared icons, all checked
Scans every <link rel="icon">, apple-touch-icon, mask-icon, and msapplication-TileImage — requests each one and measures its response.
Convention fallbacks
Probes /favicon.ico and /apple-touch-icon.png at the site root, even when the page does not declare them. A missing root fallback is the most common cause of a blank browser tab.
Consumer summary
Tells you what a browser tab, Google Search result, and iOS home-screen bookmark would each end up using — and which of those three has nothing to use.
Format mismatch detection
Compares each icon's declared type against the actual Content-Type the server sent. A mismatch means a browser may refuse the icon even though it loaded.
Real pixel dimensions
Reads image headers from PNG, ICO, GIF, JPEG, and WebP to report the actual pixel dimensions — not just what the sizes attribute claims.
Secure by default
Every request is validated for SSRF safety. No private, loopback, or link-local addresses are ever reached. Redirects are followed and re-validated at each hop.
How it works
Paste a URL
Any public website URL. Faviview accepts bare domains and adds https:// automatically.
Icons are probed
Faviview fetches the page, parses every icon declaration, then requests each one to check its status, content type, and dimensions.
Read the report
A table shows each icon's status, real dimensions, and format match. The consumer summary tells you which endpoints have nothing to display.