Favicon Testing Checklist: Validate Icons Across Browsers, Bookmarks, PWAs, and Search Previews

Overview

Favicon QA is more than checking whether a small image appears beside a page title. A website may expose several icon sources at once: HTML link elements, an ICO or PNG file, an SVG favicon, a web app manifest, and platform-specific touch or shortcut icons. Different surfaces may read different files, retain an older version, or apply their own size and cropping behavior.

Start by defining the surfaces your site actually supports. For a standard website, test at least the browser tab, bookmarks or favorites, browser history, and the address bar. For an installable web app, add the manifest, installation prompt or install flow, launcher icon, splash or launch screen where applicable, and the installed app window. If your site is discoverable through search, inspect how its favicon is represented in search previews without assuming that a successful browser test guarantees the same result there.

Before testing, record the intended icon set and URLs. A typical inventory includes:

• The primary favicon reference in the document head.
• Fallback PNG or ICO files, if your compatibility plan uses them.
• Any SVG favicon and its declared MIME type.
• The web app manifest and its referenced icons.
• Platform-specific touch, shortcut, or pinned icons used by the project.

For dimensions and format decisions, compare your implementation with this favicon size guide. If the icon is being replaced, use a versioned filename or follow a deliberate cache-busting plan rather than changing files randomly during QA.

Checklist by scenario

1. Source files and HTML

• Open each published icon URL directly and confirm it returns the intended file, not an application error page or redirect loop.
• Check the response content type and confirm it matches the file format.
• Inspect the document head for the expected rel, href, and type values.
• Confirm relative paths resolve from the production page, not only from a local development route.
• Check that the icon is available over the same secure origin and is not blocked by access controls, a failed deployment, or an incorrect base path.
• Test a page below the site root, such as /docs/example, because path errors can remain hidden on the homepage.

Keep the markup intentional. Multiple competing declarations can make troubleshooting harder. If you support SVG, PNG, or ICO together, document which one is the preferred source and which ones are fallbacks. The SVG favicon guide provides a useful review point for SVG-specific security, accessibility, and compatibility considerations.

2. Browser tabs, history, and bookmarks

• Load the production homepage in each target browser and verify the tab icon at normal zoom.
• Open a deep link and confirm the icon remains present when the page is not at the root path.
• Navigate between pages and check for inconsistent icons caused by different layouts or templates.
• Bookmark the page, close and reopen the browser, then inspect the bookmark entry.
• Search browser history for the site and check whether the intended icon appears there.
• Open several tabs so the icon is judged at its smallest practical size.

Repeat this on a clean browser profile or a device that has not previously visited the site. That comparison helps distinguish a genuine delivery problem from a cached icon. Also test a returning profile, because real users may have older favicon data stored locally.

3. Mobile browser and home-screen testing

• Open the site on at least one physical mobile device or a representative device environment.
• Check the icon in the mobile browser interface and when saving a shortcut to the home screen.
• Inspect the result after relaunching the browser or device, rather than only immediately after saving.
• Look for unwanted transparent padding, clipping, or a background that disappears against the launcher.
• Verify that the mark remains recognizable when reduced to a small square.

A favicon and a home-screen icon may use different source files or manifest entries. Do not treat a successful tab test as proof that the mobile shortcut is correct.

4. PWA and manifest testing

• Confirm the manifest URL loads successfully from the production origin.
• Validate its JSON syntax and inspect the icon entries, including their URLs, declared sizes, and image types.
• Open every manifest icon URL directly and check that the files are reachable.
• Test the install or add-to-device flow in each supported environment.
• Inspect the installed icon in the launcher and the application window, where applicable.
• After changing an icon, remove the installed version and repeat the installation test.

Use browser developer tools to inspect the manifest and any installability diagnostics available in your chosen environment. A manifest can be syntactically valid while still pointing to a missing asset, an incorrect path, or an image that does not suit the intended display size.

5. Search and shared previews

• Confirm the production site is publicly accessible to the systems that need to fetch its icon.
• Check that the favicon is not restricted by an accidental staging rule, authentication layer, or deployment path.
• Review the page source and final rendered document to ensure the intended icon reference is present.
• Record the date and URL when checking a search or sharing preview, because remote previews can update separately from your deployment.

Search previews and third-party surfaces are not fully controlled by the site owner, so report them as observed results rather than guaranteed behavior. If the browser, manifest, and direct asset tests pass but an external preview is stale, investigate fetching and cache timing before changing valid production markup.

What to double-check

Review the design at both normal and reduced sizes. A detailed logo may look balanced on a large canvas but become an indistinct shape in a tab. Test light and dark browser themes, high-density screens, and backgrounds that differ from your brand palette. The dark mode and high-density favicon checklist can help identify contrast and legibility issues.

Inspect transparency carefully. An icon with a transparent outer edge may disappear against a dark launcher or browser surface, while a solid background may create an unintended square around a mark. Check the visual center as well: optical centering is often more useful than mathematically centering an irregular symbol.

Then review the delivery chain:

• Does the source reference point to the production asset?
• Does the asset return the expected status and content type?
• Does every referenced manifest icon exist?
• Do redirects preserve the final asset format and path?
• Are staging and production using distinct, intentional icon sets?
• Does a deep link resolve the same favicon references as the homepage?

For a useful QA record, capture the environment, page URL, icon URL, surface tested, expected result, observed result, and screenshot or developer-tools evidence. This turns “favicon not showing” into a reproducible defect rather than a vague visual report.

Common mistakes

• Testing only the homepage: A root-relative path can work on one route while failing on nested pages.
• Testing only in a warm cache: Your browser may display an old icon even after a correct deployment.
• Changing several variables at once: Replace one reference or asset at a time so the failing layer remains identifiable.
• Confusing file existence with valid delivery: A file in the repository is not proof that production serves it at the expected URL.
• Ignoring the manifest: Browser-tab success does not validate an installed web app icon.
• Using an image with excessive padding: The file technically loads, but the mark can appear too small to recognize.
• Assuming one browser represents every surface: Include the browsers, devices, and install paths that matter to your audience.
• Rebranding without a cache plan: Old icons can remain visible after deployment. Use the favicon rebrand checklist when replacing an established identity.

When to revisit

Run the full checklist before a new site launch, after a favicon redesign, during a framework or routing migration, and whenever hosting, CDN, domain, or deployment configuration changes. Repeat it after adding a PWA install flow, changing manifest entries, introducing a new browser support target, or moving assets between repositories.

For an established site, a lighter review can be scheduled before seasonal planning cycles or other routine release audits. Recheck sooner when users report a missing or outdated icon, when a bookmark shows the wrong brand, or when an installed shortcut retains an earlier design.

Finish each review with a small QA report:

1. List the tested URLs, browsers, devices, and install surfaces.
2. Mark each result as pass, fail, blocked, or not applicable.
3. Attach screenshots for visual defects and network or manifest evidence for delivery defects.
4. Record the deployed asset version and test date.
5. Assign an owner and retest after the fix, including a clean-profile check.

Keep this report with the release notes or deployment checklist. A repeatable record makes favicon QA faster the next time a site is launched, rebranded, migrated, or reviewed for browser compatibility.