Quick answer
Request each declared favicon and record the final URL, status, Content-Type, Cache-Control, ETag, Last-Modified and byte length. A browser can keep an older icon even when the HTML points to a correct-looking filename.
- Last verified
- July 31, 2026
- Evidence
- Primary documentation plus transparent editorial analysis
- Primary sources
- 2
Favicon Cache Headers, Versioning and Rebrands: key distinctions
| Situation | Recommended response |
|---|---|
| Stable /favicon.ico | Allow revalidation with ETag or Last-Modified |
| Content-addressed filename | Use long-lived immutable caching |
| Rebrand release | Deploy bytes and declarations together, then purge the CDN |
| Stale existing profile | Verify production first, then clear only the affected client layer |
Prove the origin response first
Request each declared favicon and record the final URL, status, Content-Type, Cache-Control, ETag, Last-Modified and byte length. A browser can keep an older icon even when the HTML points to a correct-looking filename.
Check the origin and CDN separately when possible. A stale edge object, service worker or rewrite can return different bytes from the application instance you just deployed.
Connected next stepWhy Browsers Request /favicon.ico—and How to Stop the 404 for the closest prerequisite or comparison.
Choose a caching policy
Long-lived caching is appropriate for content-addressed or versioned icon filenames. Stable conventional URLs such as /favicon.ico need revalidation rules that allow a corrected response to propagate without an indefinite immutable lifetime.
Use validators such as ETag or Last-Modified consistently. Avoid no-store for public identity assets because it creates repeated transfers without solving saved-browser, home-screen or search caches.
Connected next stepFavicon Not Showing? Diagnose It in Seven Checks for the next connected implementation decision.
Change a favicon without fragmenting identity
For a rebrand, deploy the new bytes and declarations together. A versioned browser asset can help users refresh, but keep the homepage crawlable and avoid rotating the search favicon URL on every ordinary release.
Purge the CDN only after verifying the origin. Then test a direct request, a fresh profile, an existing profile, installed shortcuts and search separately; each surface owns a different cache lifecycle.
Connected next stepOpen the most relevant production tool and verify the decision with a working output.
Diagnose query-string versions
A query such as favicon.svg?v=2 creates a distinct fetch URL for clients that honor it. It does not change the underlying file format, and it should not become an uncontrolled parameter pattern across page URLs.
Document the chosen asset version in the release record. Remove obsolete declarations once the new candidate is stable so browsers do not select conflicting files.
Apply this guide with the relevant tools
Use the smallest tool that verifies the specific decision described above. Each destination keeps the source format, deployment evidence, or platform purpose explicit.
Review the headings, sources, implementation artifact, and update record for this guide as structured JSON.
Download guide evidence ↓- Guide
- Favicon Cache Headers, Versioning and Rebrands
- Coverage
- Client behavior can change by browser, operating system, platform version, cache state and deployment configuration. Unperformed manual observations are not claimed.
Questions, answered
Should favicon files use immutable caching?+
Only when the filename changes with the content. Stable root filenames should be allowed to revalidate.
Does clearing the browser cache update Google?+
No. Browser storage and Google’s crawl and processing systems are separate.