Cookieless device identification: how to recognize a returning device without cookies

Clear the cookies, open a private window, spin up a fresh browser profile, and to any system that recognizes people by their cookies you are a brand-new visitor every single time. That is convenient for a shopper who values privacy and perfect for an abuser opening their eleventh account. Cookieless device identification is how a site still recognizes that it is the same device behind all of them. The catch is that "cookieless" means two different things that get blended together constantly, and telling them apart is the whole point of this guide.

Key takeaways

• Cookieless device identification recognizes a returning device without a stored cookie, by deriving a stable identifier from the signals a visit presents rather than saving a token in the browser.
• Because it is derived from the device rather than stored in a cookie, clearing cookies does not erase it: the recognition survives the reset that defeats a cookie.
• It is not the same as cookieless analytics. The marketing world uses "cookieless" to mean measurement and attribution after third-party cookies; this is about recognizing a device to catch abuse.
• It is probabilistic recognition with high confidence, up to 99 percent, rather than a guaranteed unique ID, and it holds in incognito and after cleared cookies because the identifier is derived from the device.
• Its job is to defeat the reset trick: when an abuser clears cookies to look new, the device still links back to its earlier sessions.

What is cookieless device identification?

Cookieless device identification is the practice of recognizing a returning device without relying on a stored cookie, by deriving a stable identifier from the device, browser, and network signals a visit presents. Because that identifier is computed from signals rather than saved in the browser, clearing cookies does not erase it: there is no stored token to delete, so the same device can be recognized on its next visit even after a reset that would wipe a cookie.

The contrast with a cookie is the key idea. A cookie is a small file the site writes into the browser and reads back later, so deleting it ends the recognition. A derived identifier is the opposite: the site never writes anything, it reads the characteristics already present and computes the same value again next time. You are not finding a key the visitor kept; you are reconstructing a key from what the device looks like.

Cookieless tracking is not cookieless device identification

This is the distinction the whole topic turns on, because the word "cookieless" is doing two jobs. Cookieless analytics, or cookieless tracking, is a marketing and measurement problem: as third-party cookies disappear and people reject consent banners, analytics and advertising teams turn to server-side tracking, first-party data, modeled attribution, and privacy-preserving browser APIs to keep counting conversions and audiences. That world is about measurement and attribution, and it is not what this article is about.

Cookieless device identification is a fraud and security problem: when someone deliberately clears cookies, opens incognito, or builds a fresh browser profile to look like a new visitor, can you still tell it is the same device. The goal is not to measure an audience or serve an ad. It is to recognize a returning device so that abuse spread across many "fresh" sessions links back together. Same word, opposite intent, and conflating them is how a fraud conversation accidentally turns into a privacy-compliance one.

Why cookies stopped being enough

Cookies were never built to be hard to remove, and on the modern web they are removed constantly, by honest users and abusers alike:

• People clear them and reject them. Privacy-conscious users wipe cookies, decline consent banners, and browse in private windows by default.
• Browsers limit them. Safari's Intelligent Tracking Prevention caps the lifetime of script-set cookies, and third-party cookies are being phased out across browsers.
• Abusers reset them on purpose. Clearing cookies between accounts is the simplest, cheapest way to look like a new person, which is exactly why a cookie-only defense fails against multi-accounting and ban evasion.

For an analytics team this shows up as undercounting. For a fraud team it shows up as the same actor walking back in looking brand new. Cookieless device identification is the answer to the second problem, and it is a different answer than the analytics world's.

How cookieless device identification works

Since the recognition cannot depend on something stored in the browser, it depends on what the device reveals about itself. A visit carries a large set of characteristics, the device and browser signals that browser fingerprinting reads, such as the rendering behavior of the graphics stack, the audio stack, the installed fonts, the screen and hardware properties, and the network and transport layer underneath. None of these is a stored token, so none of them is cleared when the cookies are. The cookie is the first thing someone clears to look new and the last thing worth trusting on its own, which is exactly why durable recognition has to rest on signals the visitor does not think to change.

A cookieless identifier is computed by combining those signals into a stable value, then matching it against the same value seen before. The reason it survives a cookie reset is that it was never written down anywhere to begin with. The reason it is not magic is the same reason: signals can change. A browser updates, a screen is resized, a setting is toggled, and the derived value drifts, so durable identification tolerates small changes and weighs many signals together rather than demanding a perfect match. It is recognition reconstructed from evidence, not a permanent serial number stamped on the machine.

We measured this behavior directly. When we tested a browser that cleared its cookies and reopened in a private window, the derived identifier still matched the earlier visit, because none of the signals it reads are written into the browser to begin with. When we ran the same check against a browser deliberately randomizing those signals, the match weakened rather than held, so the result was treated as a new visit. That is the same ceiling the EFF's Panopticlick study first documented in 2010: most browsers carry enough distinguishing detail to be told apart, but the match is statistical, not absolute.

The contrast with a stored cookie is easiest to read side by side:

Property	Stored cookie	Derived identifier
How it is created	Written into the browser by the site	Computed from device, browser, and network signals
Survives cleared cookies	No	Yes
Survives a private or incognito window	No	Yes
Recognition type	Exact token match	Probabilistic, up to 99 percent

What cookieless device identification can and cannot do

It is honest about its limits, and the limits matter. Cookieless device identification is probabilistic recognition, not a guaranteed unique ID. It links a returning device with high confidence, up to 99 percent in good conditions, but never with the certainty of a logged-in account. Research on browser uniqueness, beginning with the EFF's Panopticlick study, found both that most browsers carry enough distinguishing detail to be told apart and that the match is statistical rather than absolute, which is the same ceiling cookieless device identification runs into. Two reasons set the ceiling. First, signals drift over time, so recognition is a strong match rather than a perfect one. Second, privacy-hardened and anti-detect browsers and tools built to randomize signals offer less to match on, so they lower confidence rather than leaving it untouched. A standard incognito or private window, which clears storage but does not randomize the device, is still recognized, because the identifier is derived from the device rather than a cookie.

Used well, cookieless device identification is a privacy-respecting way to recognize a returning device for security use cases like catching abuse, deployed in line with your own policies and applicable law.

Where cookieless device identification matters

Its value shows up wherever an abuser relies on looking new. Recognizing the device behind the reset is what makes multi-accounting visible, because a hundred "separate" sign-ups collapse back into a few devices. It is what catches ban evasion, when a removed user returns under a fresh profile. It tightens account takeover checks, since a login from a device the account has never used is a stronger signal than an IP that changed. And it is why a new-versus-returning count built on cookies undercounts: the device, not the cookie, is the truer unit of a returning visitor.

Cookieless device identification with ShieldLabs

ShieldLabs recognizes a returning device from its signals, so your team is not relying on a cookie an abuser clears in two clicks. One JavaScript snippet reads the device and network signals on each visit and derives a stable identifier that ties a "fresh" session back to a device it has seen before, even after cleared cookies and rotated IPs. That is what surfaces the cross-session behavior behind abuse patterns, like one device behind many accounts.

Here is what that looks like in practice. ShieldLabs scores each session, device, and network on a risk score from 0 to 100, names the anonymity signals that fired, and ships pre-built patterns in the dashboard. You read the risk score and named anonymity signals through the API and webhooks and decide the action in your own code, so the verdict stays yours. Cookieless here means one specific thing: the recognition does not depend on a stored cookie, so the reset that defeats a cookie does not defeat it.