Anti-Bot

What Is Favicon Fingerprinting?

What Is Favicon Fingerprinting? — conceptual illustration
On this page

Favicon fingerprinting (the “Supercookie” technique) abuses the browser’s separate, long-lived favicon cache to store a persistent identifier that ordinary cookie controls do not clear. Because the favicon (F-cache) is keyed per-path and survives incognito sessions and normal cache clears, a site can encode bits of a unique ID by controlling which favicon paths a browser is forced to request, then reading back the hit/miss pattern on a later visit.

Quick facts

Disclosed2021, "Supercookie" research by Jonas Strehle
AbusesThe dedicated, persistent favicon (F-cache)
SurvivesIncognito, cookie clears, normal cache flush
Encodes ID viaHit/miss pattern across N favicon paths (N bits)
StatusBrowsers partially mitigated; concept still instructive

How the favicon supercookie works

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. To write an ID, the server redirects a first-time visitor through a sequence of paths, serving (or withholding) a favicon at each so the browser caches 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 presence/absence pattern reconstructs the stored bits. With ~32 paths you get a 32-bit identifier.

Why it matters for scraping and privacy

Favicon fingerprinting is a reminder that stateful tracking is not limited to cookies and localStorage. A scraper that rotates cookies but reuses the same browser profile can still be correlated across sessions through the favicon cache and similar caches (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 class of attack (persistent side caches as supercookies) remains relevant.

Defending against it when scraping

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 discarded afterward. Reusing one long-lived profile across thousands of requests lets the cache accumulate into a stable identifier that ties your sessions together.

Fresh, disposable profiles also matter because an empty favicon cache on every visit is itself slightly anomalous for a "returning" user — so for stateful crawls you want the cache to persist within a 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.

Related terms

Concept map

How Favicon Fingerprinting (Supercookies) connects

The terms most directly tied to this one. Hover a node to see its neighbours, click to preview, drag to rearrange.

0 terms · 0 connections
You are here · Anti-Bot
Building map…

Frequently asked questions

Does clearing cookies stop favicon tracking?

No. The favicon cache is separate from cookies and from the normal cache clear in many browser versions, which is exactly what made the Supercookie technique powerful.

Is this still exploitable today?

Browsers shipped partial mitigations and cache partitioning after 2021, but persistent side-caches as supercookies remain a live research area. Treat any reused profile as potentially correlatable.

How should a scraper defend against it?

Use a fully isolated, fresh browser profile per identity rather than reusing one profile with rotated cookies. Disposable containers or per-session profiles prevent cross-session correlation.

Last updated: 2026-05-28