You test favicons before launch by scanning your production URL (not localhost), confirming every declared icon file returns HTTP 200, checking /favicon.ico at the root, and verifying manifest icons for PWA and mobile home screens. A quick tab refresh in Chrome is not enough. Crawlers, iOS, and Android read different tags than your desktop browser.
This guide walks through a repeatable pre-launch workflow so you catch broken paths, missing sizes, and cache traps before users do.
Why favicon testing gets skipped
Teams ship favicons late. Design hands over a PNG, someone drops it in the repo, and the deploy goes out. The tab icon looks fine on one laptop, so nobody checks bookmarks, iOS home screen, or the /favicon.ico fallback.
That works until:
- Production serves a 404 for
/favicon.icowhile HTML links point elsewhere - Staging icons leak into production because of a wrong base URL
- Apple Touch Icon is missing and iOS scales up a blurry 32×32
- Manifest icons 404 and Android PWA install shows a generic placeholder
- CDN cache serves last month's icon after a rebrand
Favicon bugs are small but visible. They show up in every browser tab, bookmark bar, and shared link context where your brand should appear.
What to test (the full stack)
Modern sites need more than one file. At minimum, verify these layers on the live domain:
| Layer | What to check |
|---|---|
HTML link tags | rel="icon", apple-touch-icon, manifest |
| Root fallback | https://yoursite.com/favicon.ico |
| PNG sizes | 16×16, 32×32 declared with correct sizes |
| Apple Touch Icon | 180×180 PNG, square crop |
| Web manifest | 192×192 and 512×512 icons, valid JSON |
| SVG (optional) | type="image/svg+xml" with PNG fallback |
Cross-reference sizes in the Favicon Sizes Guide. This testing guide assumes you already exported the right files.
Step 1: Scan the live URL with Favicon Check
Start with an automated scan. Open Favicon Check, paste your production URL, and run the check.
The tool fetches your HTML like a browser would and reports:
- Every
link rel="icon"andapple-touch-icontag - Whether
/favicon.icoexists at the domain root - Manifest icon entries if a web app manifest is linked
- HTTP status for each icon URL
This catches the most common launch failures in under a minute: wrong paths, missing files, and tags pointing to dev domains.
Tip: Test the exact URL users bookmark. If you redirect www to apex (or the reverse), run the scan on both variants. Some setups serve different HTML per host.
Step 2: Verify View Source, not DevTools alone
JavaScript frameworks inject favicon tags at runtime. DevTools shows the final DOM, which looks correct. Crawlers and some validators read the initial HTML response.
Right-click the page, choose View Page Source, and search for rel="icon".
Confirm:
- Tags appear in the raw HTML
hrefvalues are absolute or root-relative (/favicon-32x32.png, not./icons/favicon.pngthat breaks on nested routes)- No duplicate conflicting tags from plugins or legacy templates
If tags only exist after client-side hydration, fix server-side rendering or static export before launch. See How to Add a Favicon (HTML) for the baseline markup.
Step 3: Hit icon URLs directly
For each URL listed in the scan, open it in a new browser tab.
Check:
- HTTP 200 (not 301 to the wrong file, not 403 behind auth)
- Correct image (not an old logo from cache)
- Expected dimensions when you save and inspect the file
Common failures:
/favicon.icoreturns HTML error page with 200 status (misconfigured server)- Icon path includes a build hash that changed after deploy
- CDN blocks hotlinking for icon paths
Step 4: Test browser tab rendering
Automated scans confirm files exist. You still need eyeball checks in real browsers.
Desktop Chrome and Firefox
- Open a fresh incognito window (avoids cache)
- Load your homepage
- Check the tab icon at 100% zoom and 125% zoom (retina scaling)
Safari (macOS)
Safari is stricter about SVG favicons and caching. Test pinned tabs if your audience uses them.
Edge
Edge on Windows may pull from favicon.ico even when PNG links exist. Confirm the ICO file matches your current brand.
If the icon looks blurry, read Favicon Looks Blurry? Fix Pixelation. Testing and fixing blur are separate steps.
Step 5: Test iOS home screen icon
On an iPhone or iPad:
- Open Safari to your production URL
- Tap Share, then Add to Home Screen
- Confirm the preview icon is sharp and square (not a tiny logo in a white box)
If the preview is wrong, your apple-touch-icon tag is missing or points to the wrong size. The scan in step 1 should flag this.
Step 6: Test Android and PWA manifest icons
If you ship a web app manifest:
- Confirm
link rel="manifest"appears in View Source - Open the manifest URL directly and validate JSON
- On Android Chrome, use Install app or add to home screen
- Verify the installed shortcut icon matches 192×192 or 512×512 assets
Missing manifest icons do not affect desktop tabs but break Android home screen branding.
Step 7: Test bookmarks and history
Create a bookmark for your site in a clean browser profile. Some browsers pick 16×16 from ICO while tabs use 32×32 PNG. Bookmarks expose size gaps.
Also check:
- Browser history list icon
- Password manager saved-login icon (often uses favicon)
Step 8: Clear cache the right way
If you replaced icons after a previous deploy, your team may still see old icons due to aggressive favicon caching.
Reliable cache busting:
- Rename files (
favicon-v2.ico) and update HTML references - Append a query string only if your CDN respects it (
/favicon.ico?v=2) - Hard refresh does not always clear favicon cache; test incognito
For a full rebrand, plan icon URL changes in the same deploy as HTML updates.
Pre-launch checklist (copy-paste)
Use this list on every release that touches branding:
- Favicon Check scan passes on production URL
-
/favicon.icoreturns 200 with current logo - 16×16 and 32×32 PNGs declared and reachable
-
apple-touch-icon180×180 present - Manifest icons 192×192 and 512×512 present (if PWA)
- View Source shows tags without JS
- Incognito tab test in Chrome and Safari
- iOS Add to Home Screen preview checked
- No staging URLs in
hrefattributes - OG tags checked separately on Open Graph Check
Favicons and Open Graph images are different jobs. Run both scans before a marketing launch.
Common pre-launch mistakes
Testing localhost only
Local dev servers serve files from memory or different paths. Production may 404 the same relative paths. Always test the deployed URL.
Assuming one PNG is enough
A single 32×32 file covers basic tabs but fails iOS home screen and Android install surfaces. The scan reveals gaps fast.
Forgetting /favicon.ico
Browsers request it automatically. If you skip it, email clients and older tools show a generic icon even when PNG tags work.
Ignoring www vs non-www
Favicon tags on www.example.com may differ from example.com. Pick a canonical host and test both until redirects are consistent.
Skipping manifest when you have a PWA
Tab favicon and manifest icons are separate. Chrome install UI reads manifest only.
When to also run Open Graph Check
Favicons appear in browser chrome. Open Graph images appear when someone shares your link on Slack, LinkedIn, or iMessage.
Before a launch announcement:
- Run Favicon Check for icon coverage
- Run Open Graph Check for social preview tags
Different tags, different surfaces, same deploy window. Catching both prevents the awkward case where your tab icon is perfect but shared links show no image.
FAQ
How do I test favicons without publishing?
You cannot fully test favicons without a publicly reachable URL. Browsers and scanners fetch icons over HTTP. Use a staging domain with auth disabled for icon paths, or a preview deployment URL. Localhost-only testing misses CDN, redirect, and path issues.
Does Google Search Console test favicons?
Google Search Console may show favicon status for search results, but it is not a pre-launch testing tool. Use a dedicated favicon scanner plus manual browser checks before go-live.
Why does my favicon work locally but not in production?
Common causes: wrong base tag or asset prefix, icons not copied to the build output folder, CDN caching old files, or server blocking /favicon.ico. Compare View Source on local vs production and hit each icon URL directly.
How long does favicon cache last?
Browsers cache favicons aggressively, sometimes for days. After a fix, test in incognito or rename icon files. See Favicon Not Showing if users report stale icons post-launch.
Should I test favicons on every deploy?
Test on any deploy that changes icons, HTML head, manifest, or CDN config. Pure content deploys usually do not need a full favicon pass unless your CMS touches head tags.
Can I automate favicon testing in CI?
Yes. Fetch production HTML, assert required link tags exist, and HEAD-request each icon URL for 200 status. A manual scan with Favicon Check still helps designers verify visual quality.
What is the fastest pre-launch favicon test?
Paste your production URL into Favicon Check, fix any 404s it reports, then open one incognito tab and one iOS home screen preview. That covers roughly 90% of real-world failures in five minutes.
Do I need to test both light and dark mode favicons?
If you ship media="(prefers-color-scheme: dark)" icon variants, test both in browsers that support them (Safari, some Chromium builds). Otherwise a single default icon is enough for most sites.
Conclusion
Testing favicons before launch means scanning the live URL, verifying every file returns 200, checking View Source for server-rendered tags, and spot-checking tabs, bookmarks, and mobile home screens. One PNG and a quick refresh is not a test plan.
Run Favicon Check on production, walk through the checklist above, and pair it with Open Graph Check when you ship share metadata in the same release. You will catch broken paths and stale cache before users notice.