Tracking That Ignores Your Cookie Settings

Clear your cookies, switch to private browsing, do everything a privacy guide tells you, and a fingerprinting script can still recognize you. That's the whole point of it. Browser fingerprinting identifies a visitor from the combination of characteristics their browser and device expose, not from anything stored on the machine. Nothing is written, so there's nothing to delete.

This is why fingerprinting sits at the center of the browser privacy fight. A cookie is visible, controllable, and consented. A fingerprint is silent, and until browsers stepped in, users had no way to see it or stop it. Understanding it matters because a cookie banner that only thinks about cookies can miss it entirely.

What Gets Measured

Individually, most of these signals are unremarkable. Combined, they're often unique enough to single you out of millions:

Screen resolution, color depth, and device pixel ratio
Installed fonts and language settings
Operating system, browser version, and time zone
Hardware hints like CPU cores and available memory
Canvas rendering, where a script draws hidden text or graphics and reads back the exact pixels, which vary by GPU, drivers, and OS
WebGL and Web Audio, which expose subtle hardware-specific rendering and signal-processing differences

Canvas fingerprinting is the classic example: two machines drawing the same instruction produce slightly different pixels, and that difference is stable enough to act as an ID. Because the identifier is computed on the fly from your hardware, clearing storage does nothing to it.

Why Browsers Decided To Block It

Browsers spent years restricting third-party cookies. Fingerprinting is the obvious way around all of that work, so it became the next target. It's the tracking method that survives cookie blocking, private mode, and manual clearing, which makes it the one users have the least ability to escape on their own. Every major privacy-focused browser now treats fingerprinting scripts as something to defeat, and they've split into two philosophies:

Randomization. Brave's farbling adds tiny, per-site, per-session noise to the values a fingerprinting script reads, so the same person looks like a different visitor everywhere. The output is plausible, so sites don't break, but it's useless for tracking.
Uniformity or blocking. Firefox blocks known fingerprinting scripts through Enhanced Tracking Protection, and its resistFingerprinting mode tries to make every user report the same generic values. Safari's WebKit limits the APIs that fingerprinting scripts lean on, restricting access to the signals that make a fingerprint distinctive.

Each approach has tradeoffs. Randomization can be probed over many samples; forced uniformity can make the rare users who enable it stand out precisely because they look identical. There's no perfect defense, which is why browsers keep iterating.

How Unique Is A Fingerprint, Really

The reason a handful of dull technical details can identify you is math, not any single revealing signal. Each attribute carries a little information: your time zone narrows you to a region, your screen size to a group, your font list to a smaller group still. Multiply enough narrow filters together and the intersection is often a single person among millions. Researchers have shown that a fairly ordinary combination of browser and device attributes is frequently unique across very large populations.

Two consequences follow. First, you can't fix fingerprinting by hiding one field, because uniqueness comes from the combination, not any one value. Second, this is why the browser strategies split the way they do: randomization poisons the combination so it changes constantly, while forced uniformity tries to make everyone's combination identical. Both attack the same weakness, that a stable, distinctive set of values is what makes tracking possible.

Fingerprinting Is Not a Cookie Loophole

Some vendors pitch fingerprinting or "cookieless identification" as a way around consent, on the logic that no cookie is set. That reasoning is wrong under EU law. The ePrivacy Directive governs "the storing of information, or the gaining of access to information already stored" on a user's device. Reading the canvas output, font list, and hardware hints to build an identifier is gaining access to information on the device, so it needs the same prior consent a cookie does. Regulators and the EDPB have been explicit that device fingerprinting for tracking is not a consent-free shortcut. If you fingerprint for tracking, gate it behind consent like anything else.

The Blind Spot In Cookie-Only Thinking

Here's the practical risk for a site operator. If your consent tooling only reasons about document.cookie, a fingerprinting or cookieless tracking script can run and identify visitors without ever tripping a cookie-based check. Your banner says "we use cookies," your scanner counts cookies, and meanwhile a script is building device IDs that never touch cookie storage. You end up out of compliance while believing you're covered.

The fix is to inventory behavior, not storage alone. A script that phones out to a tracking endpoint is doing something that needs a legal basis, whether or not it drops a cookie. See How to Audit Your Website's Cookies and First-Party Data Strategy for the broader shift away from stored identifiers.

Where CookieBeam Fits

CookieBeam's scanner detects the outbound network connections your pages make, alongside the cookies they set. That's the layer where fingerprinting and cookieless tracking become visible, because these scripts still call home to a collection endpoint even when they store nothing locally. Surfacing those connections lets you decide which need a consent category and gate them accordingly, so "cookieless" doesn't quietly mean "consent-less." The browsers protect their own users from fingerprinting; your job is to make sure the scripts you deploy have a basis for every visitor, in every browser.

Related Guides and Sources

Keep reading: Brave Browser and Shields, Firefox Total Cookie Protection and ETP, and Safari ITP Explained for Marketers. Primary sources: WebKit's Tracking Prevention policy and Mozilla's Enhanced Tracking Protection, both of which document their fingerprinting defenses.