Favicon Not Showing? A Troubleshooting Checklist for Browsers, CMSs, CDNs, and Mobile Devices

Overview

The goal of favicon troubleshooting is to separate design problems from delivery problems. A favicon not showing can come from the wrong file format, incorrect HTML, stale caches, CMS overrides, CDN behavior, or platform-specific icon expectations. In practice, the fastest path is to verify the simplest layers first.

Start with this baseline sequence:

1. Confirm the icon file exists at the expected URL and loads directly in the browser.
2. Confirm the HTML head includes the intended icon references, not old or duplicate ones.
3. Confirm the file format and dimensions make sense for the browsers and devices you care about.
4. Confirm the server and CDN are actually serving the updated file, not an older cached version.
5. Confirm the browser or device is not holding onto an old favicon.

It also helps to define what “not showing” means in your case. The favicon may be:

• missing entirely in browser tabs
• showing the old icon after an update
• visible on desktop but not on mobile
• working in one browser but not another
• appearing in tabs but not bookmarks, home screen shortcuts, or pinned surfaces
• blurry, cropped, or unreadable at small sizes

Those symptoms point to different root causes. For example, a favicon cache problem often looks different from a sizing problem or a CMS override.

If you are still refining the asset itself, it helps to review How to Create a Favicon From a Logo Without Losing Clarity at 16x16 and Favicon Size Guide 2026: Every Icon Dimension You Need for Browsers, iPhone, Android, and PWA before debugging delivery.

Checklist by scenario

Use the scenario that matches the symptom you see first. This saves time and reduces blind changes.

Scenario 1: The favicon is not showing at all

When a favicon not showing issue is total rather than partial, check these items in order:

1. Open the favicon URL directly. If it 404s, redirects oddly, or downloads instead of rendering, solve that first.
2. Inspect the page source or rendered head. Make sure your link rel="icon" points to a real file and correct path.
3. Check for path mistakes. Relative URLs often break after theme, routing, or deployment changes. An absolute path from the site root is usually easier to audit.
4. Check MIME behavior. Some setups serve files with unexpected headers. Browsers can be tolerant, but inconsistent delivery can still create problems.
5. Look for duplicate icon declarations. If multiple favicon tags point to different files, browsers may choose differently than you expect.
6. Check whether the CMS injects its own favicon markup. Themes, SEO plugins, or site identity settings can override manual head tags.

If you use a site builder or managed CMS, review How to Add a Favicon in WordPress, Shopify, Wix, Squarespace, and Webflow to verify where the platform expects favicon settings to live.

Scenario 2: The favicon is showing, but it is the old version

This is one of the most common favicon troubleshooting cases. The asset may be updated on the server while one or more caches still serve or display the previous version.

1. Hard refresh the page, but do not stop there.
2. Open the favicon file URL directly and confirm whether the file itself is old or new.
3. Check the CDN cache. If your CDN caches static assets aggressively, purge the icon file or the relevant path.
4. Check application-level caches. Frameworks, reverse proxies, optimization plugins, and static site hosts may all cache asset references.
5. Use a versioned filename when practical. For example, favicon-v2.png is often easier to invalidate than reusing the same filename.
6. Update the HTML reference to point to the new versioned path.
7. Retest in a private window and a second browser. This helps distinguish a browser favicon issue from an origin or CDN issue.

A favicon not updating symptom is often solved by versioning and explicit cache invalidation, not repeated uploads to the same path.

Scenario 3: It works on desktop, but not on mobile

Mobile devices often use different icon conventions from desktop tabs. If the browser tab icon works but the mobile appearance does not, inspect the platform-specific assets.

1. Check touch icons and app-related icons separately. Mobile home screen or app-like surfaces may not use the same file as the desktop tab favicon.
2. Verify dimensions. An icon that looks acceptable at one size may scale poorly or be ignored at another.
3. Check whether the platform expects PNG, ICO, SVG, or a specific manifest reference.
4. Review your web app manifest if you use one. Missing or outdated icon references there can create inconsistent behavior.
5. Test on an actual device if possible. Emulation is useful, but some icon behaviors are easiest to confirm on hardware.

If format choice is part of the confusion, SVG vs PNG vs ICO Favicons: Which Format to Use in 2026 is a useful companion.

Scenario 4: It works in one browser but not another

When you have a browser favicon issue isolated to one browser family, assume one of three things: different format support, different cache behavior, or different fallback logic.

1. Compare the rendered head in each browser. Extensions, injected scripts, and platform tools can alter behavior.
2. Offer sensible fallbacks. A modern setup may include SVG plus PNG and, where needed, ICO compatibility.
3. Remove ambiguous duplicates. Over-declaring icon tags can create browser-specific selection behavior.
4. Test in a clean profile. Browser extensions and synced profiles can preserve old data.
5. Check bookmarks and pinned tabs separately from ordinary tabs. Some surfaces fetch icons on their own schedule.

If your current package is inconsistent, a reliable favicon generator can help you produce a cleaner icon set with predictable naming and markup.

Scenario 5: The favicon is visible, but blurry, cropped, or unreadable

Not every favicon problem is technical delivery. Sometimes the icon renders exactly as delivered, but the design does not survive small sizes.

1. Check the source artwork at 16×16 and 32×32. Do not evaluate only the large master file.
2. Simplify detail. Small icons usually need fewer elements, stronger contrast, and a bolder silhouette.
3. Check padding and safe area. Artwork too close to the edge can appear cropped.
4. Test on light and dark browser UI. Contrast can collapse in one mode.
5. Review transparent backgrounds carefully. They can disappear against certain tab or toolbar colors.

This is where workflow matters: a favicon is part of digital identity, but it has to function under technical constraints. If you generate assets from a logo or avatar, test the smallest outputs before treating the set as finished.

Scenario 6: The favicon works locally but fails after deployment

This usually points to environment differences.

1. Check base paths and asset prefixes. Production often introduces subpaths, CDNs, or rewritten asset directories.
2. Check static file handling. Some frameworks need explicit rules to publish public assets.
3. Check CSP or security rules. An overly strict policy can block expected icon loading patterns.
4. Check redirects. Redirect chains, especially between HTTP and HTTPS or between domains, can interfere with clean asset delivery.
5. Check case sensitivity. A path that works locally on one filesystem may fail in production.

For teams, it helps to make favicon validation part of deployment QA rather than a last-minute visual check.

What to double-check

Once you have isolated the likely scenario, audit these details carefully. Many favicon bugs come from small inconsistencies rather than one dramatic failure.

1. File names and paths

Make sure the file name in your markup exactly matches the published asset, including extension and case. Common breakpoints include:

• favicon.ico referenced, but only favicon.png exists
• asset moved into a build directory without updating the HTML
• relative paths breaking on nested routes
• a CMS media URL being changed after a migration

2. HTML head markup

A clean head is easier to debug than a crowded one. Double-check:

• you have a primary rel="icon" reference
• special-purpose icons are declared intentionally, not copied blindly
• old tags from previous themes or plugins are removed
• the head output in production matches what you expect from your templates

If you are unsure what the final head should look like, keep it minimal and explicit rather than relying on accumulated defaults.

3. File format choice

There is no one universal best choice for every stack. Instead, choose formats based on compatibility and maintenance needs. A modern set often includes a small number of clearly named files rather than many overlapping variations. If you are comparing favicon png vs ico or considering SVG support, prioritize a setup you can verify and maintain.

4. Caching layers

Favicon cache problems are common because the asset is both small and long-lived. Audit every layer:

• browser cache
• service worker cache if your app uses one
• CMS optimization or cache plugin
• hosting platform static cache
• CDN edge cache
• corporate proxy cache in managed environments

If you cannot confidently purge every layer, versioned filenames are often the safer route.

5. CMS and theme controls

Many platforms expose favicon settings in the admin UI and may regenerate or override markup automatically. Double-check whether the source of truth is:

• theme settings
• site identity settings
• a header injection tool
• an SEO plugin
• custom code in the template

Pick one canonical method. Multiple control points are a frequent source of confusion.

6. Manifest and platform extras

If your site behaves like a web app or supports installable experiences, inspect the manifest and related metadata. A correct tab icon does not guarantee correct app or shortcut icons.

7. Visual clarity at small sizes

Even with perfect technical delivery, a weak small-size icon still fails the user. Confirm the image remains recognizable at real tab sizes, not only in a design mockup.

Common mistakes

These are the patterns that repeatedly slow teams down during favicon troubleshooting.

• Uploading a new icon without changing the filename and assuming every cache will refresh quickly.
• Keeping old favicon tags in the head after a redesign or CMS migration.
• Testing only one browser and concluding the issue is fixed.
• Using a detailed logo as-is without optimizing it for tiny sizes.
• Forgetting mobile and manifest icons while focusing only on desktop tabs.
• Debugging the browser first instead of the asset URL. Direct file access often reveals the real problem faster.
• Letting plugins, themes, and manual code compete for favicon control.
• Ignoring deployment differences between local, staging, and production.
• Assuming one format covers every use case cleanly without testing fallbacks.

A practical team habit is to document your favicon workflow next to your deployment workflow. Include the source asset location, generated outputs, head markup, manifest references, and cache invalidation steps. That turns a recurring annoyance into a routine maintenance task.

When to revisit

This checklist is most useful when you treat favicon setup as part of identity operations, not a one-time design task. Revisit it whenever one of these events happens:

• Before a redesign or rebrand goes live. A new logo or avatar often needs a favicon-specific version, not just a resized master.
• When you change CMS, theme, or site builder settings. Platform changes can silently replace head markup.
• When you add or switch a CDN. Cache strategy can change favicon behavior immediately.
• When you introduce a web app manifest, service worker, or PWA behavior. New icon surfaces appear.
• When your build pipeline changes. Asset hashing, path rewriting, and static exports can alter icon URLs.
• Before seasonal planning cycles or major launches. This is a low-effort check that prevents an avoidable polish issue.
• Any time users report that the favicon is old, missing, or inconsistent. Their environment may expose a cache or platform path you did not test.

For a practical maintenance routine, use this short action list:

1. Keep one canonical source file for the favicon system.
2. Generate only the formats and sizes you actually need.
3. Use clear file names and avoid ambiguous duplicates.
4. Version filenames when updating published icons.
5. Audit the rendered head after each theme, CMS, or deployment change.
6. Test in at least two browsers, one private session, and one mobile device path when relevant.
7. Document where favicon settings live in your stack.

If you need to rebuild your icon package from scratch, start with a dependable best favicon generator tools comparison, then validate the final output against your real browser and device targets. For platform-specific implementation help, return to the CMS favicon setup guide. And if the issue is really about dimensions, keep the favicon size guide bookmarked.

The durable lesson is simple: most favicon issues become manageable once you stop treating them as a single file problem. They are usually an asset, markup, delivery, and cache coordination problem. With a checklist in place, that coordination becomes predictable.