How a website knows you have been there before

The simple answer and why it stopped being enough

For most of the web’s history, the answer was one word: cookies. A server sets a small text file in the browser on the first visit, the browser hands it back on every later request to that domain, and the server matches the ID inside it to a record in its database. No cookie, no memory of you. Clear the cookie, and to the server you are a stranger again.

That model still runs a huge share of returning visitor tracking today, but it has three problems that pushed the industry to build a much deeper stack underneath it. First, users delete cookies, browse in private windows, or block them outright. Second, Safari, Firefox, and increasingly Chrome have spent the last several years specifically hunting down cookies and shutting them off. Third, advertisers and platforms want to recognize a device even when a user has done everything right to prevent it, which is where things get more interesting, and more contentious.

First-party cookies and why they survived longer than the rest

A cookie set by the domain you are actually visiting, first-party.com, is treated very differently from one set by a tracking domain loaded inside that page, like adtracker.net. Browsers gate third-party cookies far more aggressively because they are the classic mechanism for following a user across unrelated sites: load the same tracking pixel on ten different retailers, and the tracker’s cookie lets it stitch a single profile together across all ten.

First-party cookies used purely for “does this browser have an account here” or “has this browser seen our consent banner” are much less contentious, and browsers generally still allow them. That is why a site can still recognize a returning visitor for its own login state or shopping cart even in a browser that aggressively blocks third-party trackers. The catch is scope: a first-party cookie only proves the browser has visited that one domain before. It says nothing about behavior anywhere else, which is exactly the boundary privacy-focused browsers are trying to enforce.

Storage that outlives a cookie deletion

Cookies are not the only place a browser can stash an identifier. localStorage and IndexedDB are per-origin storage APIs originally built for legitimate app state, but a random ID dropped into either one behaves almost identically to a cookie for recognition purposes: it persists across sessions and survives a browser restart. Historically these stores were sometimes used to resurrect an ID that a user had deliberately deleted from cookies, a technique researchers labeled “respawning” or, in its most aggressive form, the “evercookie,” which scattered the same identifier across cookies, Flash storage, ETags, and half a dozen other corners of the browser simultaneously so that clearing any one of them left the others intact.

This is precisely why modern browsers no longer treat storage clearing as a cookie-only operation. Chrome, Firefox, and Safari now bundle localStorage, IndexedDB, service worker caches, and cookies together under a single “clear site data” action, and Safari’s Intelligent Tracking Prevention caps how long any of this first-party storage survives without continued user interaction, typically capping it at seven days for scripts it classifies as tracking-related.

The cache and the network layer can leak recognition too

Some of the oldest respawning tricks did not touch storage APIs at all. HTTP caching headers like ETag and Last-Modified are designed to let a browser skip re-downloading a file it already has. A server can assign a unique ETag value per visitor for a small cached resource, like a tracking pixel, and read that same value back on the next request without ever setting a cookie. Because this lives in the caching layer rather than a storage box a user thinks to clear, it was a favorite way to quietly restore an identifier after a cookie wipe. Browsers responded by isolating the HTTP cache per top-level site, so a cache entry created while browsing site A is no longer visible to a tracker embedded on site B, which breaks the cross-site version of this trick even though same-site recognition still works.

Device fingerprinting: recognition without storing anything at all

The technique that gets the most attention, and the most misunderstanding, is fingerprinting. Instead of writing an ID to the browser and reading it back, a fingerprinting script asks the browser dozens of small, mundane questions: what fonts are installed, what the canvas element renders a specific test image as, what the WebGL renderer string reports, what audio processing produces for a synthetic waveform, what the screen resolution and color depth are, what timezone and language the system reports, what HTTP header order and TLS handshake parameters the client used.

None of these signals is unique on its own. Thousands of people share the same screen resolution. But combined, the specific set of fonts, GPU driver quirks, and audio stack behavior narrows the pool of matching devices dramatically, often to a group small enough that a site can guess, with reasonable but never certain confidence, that two visits came from the same machine. Canvas fingerprinting works because font rendering and anti-aliasing differ subtly by OS, GPU, and driver version, so the pixels a browser produces for the same drawing instructions vary in ways invisible to the eye but detectable in a hash. TLS fingerprinting works at a lower layer entirely, looking at the order and content of the cipher suites a client offers during the handshake, which varies by TLS library and version rather than anything the website’s JavaScript touches.

This is probabilistic, not deterministic, recognition. A fingerprint is a “this is probably the same device” signal, and it degrades whenever a browser updates, a font gets installed, or a user switches networks and the fingerprinting script recomputes some of its inputs. Sites that rely on it heavily are effectively running a matching model against noisy data, not reading a stable name tag.

Login state is the strongest signal, and it needs none of this

It is worth saying plainly that the most reliable way any site recognizes a returning visitor is the boring one: the user logs in. A username and password, or a session token issued after authentication, tells the server exactly who is present with no inference involved. Everything described above exists specifically for the much harder problem of recognizing a device or browser when no login has happened, which is the situation advertisers, fraud teams, and analytics platforms are usually working with.

How this gets pushed back on

Browser vendors have treated tracking-resistant defaults as a competitive feature for years now. Safari’s ITP partitions storage by top-level site and expires script-writable storage for domains it classifies as trackers. Firefox’s Enhanced Tracking Protection blocks known tracking domains outright using curated lists and randomizes some fingerprinting-relevant values like canvas output when a site’s script pattern looks like a fingerprinting probe. Chrome has moved more slowly on third-party cookies specifically because of its scale in the advertising market, but it has still shipped storage partitioning and is phasing in its own set of restrictions.

On the fraud and anti-fraud side, the same fingerprinting techniques that let an ad network recognize a returning shopper are what let a bank’s risk engine flag a login attempt from a device that does not match the account’s usual fingerprint, and what let a platform’s anti-abuse system notice when a hundred “different” new accounts all share suspiciously identical canvas and audio fingerprints. It is the same machinery pointed in a defensive direction, which is a big part of why it has not disappeared even as privacy regulation and browser defaults have made the naive cookie approach far less reliable than it was a decade ago.

None of this adds up to certainty in either direction. A fingerprint match is a probability, a cookie is proof only until it is deleted, and login state is reliable only for the account, not the human behind it. Recognizing a returning visitor on the modern web is less a single mechanism and more a layered set of imperfect signals, each one built to survive the last defense that shut the previous signal down.

Curious how the other side of this cat and mouse game works, from the browser defenses to the anti-fraud systems reading these same signals? Explore more on Hidden Internet

Get new guides and videos first — join the Telegram channel.