What Is Favicon Fingerprinting?

Browsers cache favicons in a store separate from the normal HTTP cache, optimised for speed and kept for a long time. The Supercookie attack sets up a set of redirect paths, each with its own favicon. Think of each path as one bit, and the cache as a row of those bits spelling out a number.

To write an ID, the server bounces a first-time visitor through a sequence of paths, serving (or withholding) a favicon at each one so the browser ends up caching a specific subset. To read the ID back, the server watches which favicon requests the browser makes on return: a cached favicon is not re-requested, so the pattern of which icons are present versus missing reconstructs the stored bits. With about 32 paths you get a 32-bit identifier — enough to tell billions of visitors apart.

Favicon fingerprinting is a reminder that stateful tracking — recognising you by data left behind on your machine — is not limited to cookies and localStorage (a browser key/value store websites can write to). A scraper that rotates cookies but reuses the same browser profile can still be linked across sessions through the favicon cache and similar leftovers (HSTS pins, HTTP/2 connection coalescing, the disk cache itself — see cache-timing fingerprinting). The practical defence for automation is a genuinely fresh, isolated profile per identity — not just cleared cookies. Major browsers added partitioning and mitigations after the 2021 disclosure, but the broader class of attack (persistent side caches used as supercookies) remains relevant.

Because the favicon supercookie lives in a cache that survives normal cookie clearing, the defence is isolation: give every scraping session its own browser profile or container, so the favicon cache (like cookies, localStorage and the HTTP cache) starts empty and is thrown away afterward. Reusing one long-lived profile across thousands of requests lets the cache fill up into a stable identifier that ties all your sessions together.

Fresh, disposable profiles also matter for a subtler reason: an empty favicon cache on every single visit is itself slightly odd for a "returning" user — so for crawls that need to look like a real return visit, you want the cache to persist within one session but reset between identities. Managed browser pools and a web scraping API handle this rotation for you, pairing each fresh profile with a matching proxy so the favicon cache, cookies and IP all turn over together.