Browser Fingerprinting Explained: How Sites Identify You Without Cookies

Browser fingerprinting lets a website recognise your browser from its configuration (user agent, screen size, fonts, time zone, how it draws graphics) instead of an identifier stored on your device. Nothing is saved, so clearing cookies does not reset it. What reduces it is looking like a crowd: uniform defaults, fewer exposed details, fewer unusual tweaks.

The W3C's own guidance for specification authors puts it plainly: fingerprinting is the capability of a site to identify or re-identify a visiting user, user agent or device "via configuration settings or other observable characteristics". This post goes one level deeper than our comparison of private search engines and browsers. It explains which signals make up a fingerprint, what the published research actually measured, what each major browser says it does about it, what European and UK regulators have said, and how to test your own browser step by step.

Key takeaways

• A fingerprint combines traits that each look harmless: user agent, screen and window size, fonts, time zone and language, and tiny differences in how your graphics and audio stacks render a test image or sound.
• The W3C distinguishes passive fingerprinting (headers and IP address), active fingerprinting (scripts or CSS probing the browser), cookie-like re-identification and transient event correlation.
• Eckersley's 2010 Panopticlick study saw 83.6% of 470,161 browsers as unique. The 2016 AmIUnique study found 89.4% of 118,934 unique. A 2018 study of about 2.07 million fingerprints from a mainstream French website found only 33.6% unique. Audience matters.
• Browsers defend in opposite ways: uniformity (everyone reports the same values, as Tor Browser describes) and randomisation (per-site, per-session noise, as Brave's 2020 design describes). Firefox and Safari mix reduced values, script blocking and noise. Chrome froze most user agent detail in 2022 and 2023.
• In the EU, the Article 29 Working Party (2014) and the EDPB (guidelines adopted 7 October 2024) place fingerprinting under the ePrivacy consent rule. The UK ICO said in December 2024 that fingerprinting is not a fair means of tracking and finalised its guidance on 29 April 2026.
• The most common mistake is stacking privacy extensions and custom settings. Each unusual choice can make you more unique.

What browser fingerprinting is, and how it differs from cookies

A cookie is a value a site asks your browser to store and send back. A fingerprint is a value a site computes from what your browser already is. EFF's Cover Your Tracks project compares a cookie to a tag clipped to a migrating bird, which works until the bird loses it, and a fingerprint to recognising the bird by its song and markings.

The W3C document "Mitigating Browser Fingerprinting in Web Specifications", maintained by the Privacy Working Group with the Technical Architecture Group, sorts the techniques into four types.

Passive fingerprinting

Passive fingerprinting uses only what arrives in normal requests, with no code run on the client: the HTTP headers (User-Agent, Accept, Accept-Language), the IP address and other network-level information. The W3C notes that for some populations the user agent plus IP address will often identify a particular browser. It is invisible from the browser side, because the headers are sent anyway.

Active fingerprinting

Active fingerprinting runs JavaScript (or, increasingly, CSS) on the client to read more: window size, fonts, connected devices, performance characteristics, sensor readings and the output of rendering a hidden graphic. The W3C stresses that active fingerprinting is at least potentially detectable on the client, which is what lets browsers block known fingerprinting scripts. Most fingerprinting scripts send the raw values to a server, which combines them out of sight.

Cookie-like re-identification

A site stores state somewhere the user did not expect or cannot easily clear, and reads it back later. The W3C cites the evercookie demonstration, which respawned cleared cookies from other storage. The EDPB names the HTTP ETag caching header and HSTS state as further mechanisms that can carry an identifier.

Transient event correlation

The newest W3C category links two simultaneous sessions on one device by watching for events that fire on both at once, such as a change of attached media devices. It matters only in narrow threat models, such as keeping two browsers used at the same time unlinked.

Why fingerprinting is harder to control than cookies

The W3C lists three harms: identifying a user, correlating browsing within and across sessions, and tracking without transparency or user control. The third is the one regulators keep returning to. There is a button to clear cookies, but none that clears a fingerprint, because nothing was stored; the ICO's explainer notes that clearing all site data does not stop a fingerprinting organisation from recognising you again straight away. Fingerprinting also works across origins: if unrelated sites embed the same third-party script, each computes the same fingerprint, and the script's owner can link the visits even when third-party cookies are blocked.

Which signals make up a fingerprint

No single trait identifies you. What identifies you is the combination. The table below lists the signals that research tools and browser vendors discuss most often, how a site reads each one, and what tends to make it vary between people.

User agent string and client hints

For years the User-Agent header carried the exact browser build, operating system version and, on Android, the device model. In Eckersley's 2010 data it alone carried a mean of 10.0 bits, roughly one in a thousand.

User-Agent Client Hints, a draft in the W3C's Web Platform Incubator Community Group, splits that information up. By default a supporting browser sends only three low entropy hints: Sec-CH-UA (brand and major version), Sec-CH-UA-Mobile and Sec-CH-UA-Platform. A site that wants more sends an Accept-CH response header naming hints such as Sec-CH-UA-Platform-Version, Sec-CH-UA-Model or Sec-CH-UA-Full-Version-List; scripts call navigator.userAgentData.getHighEntropyValues(). The specification says the aim is to reduce "the passive fingerprinting surface area exposed to the network". The detail is still available on request, but asking is now visible and the browser decides what to answer. The brand list also carries a deliberately meaningless GREASE entry so that sites cannot rely on an exact brand list.

Screen, window and display

Screen resolution and colour depth were worth 4.83 bits in 2010 (the paper calls the variable "video"). Modern scripts also read the available screen area, which reveals a taskbar or dock, the inner window size and the device pixel ratio. Mozilla's November 2025 post lists the size of your dock or taskbar among the details Firefox now hides.

Fonts

Fonts carried 13.9 bits in 2010, read through plugins that returned the whole system font list. Plugins are gone, but a script can still measure whether text renders differently with a named font, which reveals whether it is installed. An office suite, a design tool or a language pack can each make you stand out. WebKit says Safari exposes only web fonts and fonts bundled with the operating system, and the W3C guidance notes that Tor Browser, Firefox and Safari all limit font lists to fonts common on a platform.

Canvas, WebGL and audio

Canvas fingerprinting draws text and shapes into an off-screen canvas, reads the pixels back and hashes them. The result depends on the GPU, driver, font rasteriser and anti-aliasing. The 2016 AmIUnique study found canvas among the most discriminating attributes, especially on mobile, where it separated device models and firmware versions. WebGL adds the graphics vendor and renderer strings, which can name the exact GPU. Audio fingerprinting runs a generated signal through the Web Audio API and reads the output, which varies with the platform's audio stack and arithmetic. Safari 26 lists 2D canvas and web audio readback among the APIs it restricts for known fingerprinting scripts.

Time zone, language and hardware

Time zone carried 3.04 bits in 2010, and an unusual language list adds more. Many sites need these values legitimately; Mozilla points out that calendar and conferencing tools need your real time zone, which is why mainstream browsers rarely spoof them by default. CPU core count, touch points, memory hints, media devices and sensors add small amounts each. WebKit lists Battery Status, Device Memory, Network Information, Web MIDI, Web NFC, Web Bluetooth and several sensor APIs among features it has not implemented, partly because of fingerprinting, and it requires permission before a site can read motion and orientation sensors on mobile.

Extensions are a separate story. Many change the pages they run on or block particular requests, and a script can notice. We return to this below.

Network-level signals

The W3C document reminds specification authors that the fingerprinting surface extends to other layers of the stack, such as differences in TCP connections. These signals are passive and outside anything a page can block, which is one reason why changing only your user agent string can make you look inconsistent rather than anonymous.

How fingerprints add up: entropy and anonymity sets

Researchers measure fingerprints in bits of entropy, because bits add up and each bit halves the number of people you could be. Ten bits narrow a population to about one in 1,024, twenty bits to about one in a million, and about 33 bits single out one person among roughly eight billion, since 2 to the power of 33 is about 8.6 billion. The W3C guidance makes the same point: thirty-odd bits would be enough to single out every individual person. The other number that matters is the anonymity set, the group of people who share your exact fingerprint. Defences aim either to shrink the bits or to grow the set.

Worked example 1: what 18.1 bits means

Eckersley's paper reports that the distribution of Panopticlick fingerprints contained at least 18.1 bits of entropy. Two to the power of 18.1 is about 281,000; the paper states it as "only one in 286,777 other browsers will share its fingerprint" for a browser picked at random. Now picture a site with 10 million monthly visitors. Dividing 10,000,000 by 286,777 gives about 35. So a typical visitor's fingerprint would be shared by around 35 other visitors that month. That is not a unique ID on its own, but add an IP address range, a login or a second visit pattern and the set collapses to one.

Worked example 2: adding three signals

Take three of Eckersley's per-variable surprisal values: user agent 10.0 bits, screen ("video") 4.83 bits and time zone 3.04 bits. If they were independent, the total would be 17.87 bits. Two to the power of 17.87 is about 240,000, so the three together would narrow a visitor to about one in 240,000.

They are not independent, though. A phone model's user agent predicts its screen size, and a language predicts a time zone, so real combined entropy is lower than the sum. The reverse lesson matters for users: a value that does not fit the rest of your profile (a desktop screen with a mobile user agent, say) adds far more information than its column suggests, because so few real browsers have that combination.

Worked example 3: why audience changes the result

The 2018 "Hiding in the Crowd" study (Gómez-Boix, Laperdrix and Baudry) collected 2,067,942 fingerprints from one of the top 15 French websites between 7 December 2016 and 7 June 2017. Of those, 1,816,764 came from desktops and laptops, and 35.7% of the desktop fingerprints were unique. That is roughly 649,000 unique desktop fingerprints. The other 64.3%, about 1.17 million, shared their fingerprint with at least one other browser. For mobile, only 18.5% were unique. The authors explain the gap with earlier studies by their audience: visitors to a general French site are not people curious about fingerprinting, who tend to run unusual setups.

How unique fingerprints are in practice: what the research measured

The headline numbers people quote are often from the oldest, most self-selected datasets. Here is what each study actually measured, in date order, alongside the browser and regulatory changes that followed.

The 2010 Panopticlick study

Eckersley's fingerprint used eight variables: user agent, HTTP Accept headers, cookies enabled, screen resolution and colour depth, time zone, plugins and their versions, system fonts (read through Flash or Java) and a partial supercookie test. Plugins (15.4 bits) and fonts (13.9 bits) dominated. Fingerprints changed quickly as browsers updated, but a simple heuristic still linked upgraded fingerprints to earlier ones: the abstract reports 99.1% of guesses correct with a 0.86% false positive rate (the introduction says 0.87%). Instability does not stop tracking when the change is predictable. Eckersley also described a paradox: privacy tools used by too few people can make their users more identifiable. The sample was self-selected, which he acknowledged.

The 2016 AmIUnique study

AmIUnique analysed 118,934 fingerprints with 17 attributes, including canvas, WebGL vendor and renderer, HTTP headers, platform, Do Not Track and ad blocker presence (collected between November 2014 and February 2015, according to the 2018 paper). 89.4% were unique, and 81% of mobile fingerprints were unique despite the absence of plugins, because mobile user agents carried model and firmware details. The authors estimated that removing plugins and standardising HTTP headers could cut desktop uniqueness by 36%.

The 2018 "Hiding in the Crowd" study

On a general audience site, uniqueness fell to 33.6%. Simulating the disappearance of plugins dropped desktop uniqueness from 35.7% to 16.5%. The authors also found non-unique fingerprints "fragile": a small change to one attribute often makes them unique. (The paper gives the mobile sample as 251,166 in one place and 251,190 in another; neither changes the conclusions.)

What this means today

Fingerprinting is not magic: on mainstream audiences, most browsers share their fingerprint with others, and browser changes since 2016 measurably shrank the surface. But a fingerprint does not need to be unique to be useful, because trackers combine it with IP address, timing and any login. The W3C considers it implausible that widely deployed technical measures alone could eliminate fingerprinting by a determined adversary. Defences aim to make tracking harder, more visible and less reliable.

What browsers do about it

The W3C guidance names four levels of mitigation: a smaller fingerprinting surface, a larger anonymity set, fingerprinting that is detectable, and local state that can be cleared. Browsers mix them differently. Each browser below is described from its own documentation; this is not a ranking, and features change between releases.

Standardised outputs and uniformity

Uniformity means every user of a browser version reports the same values. The W3C guidance prefers it to randomisation for specifications, because it is easier to measure and lets one person look like a large group instead of trying to look like many different people.

The Tor Browser manual describes this approach in detail. It opens content windows rounded to multiples of 200 by 100 pixels and, when you resize, uses letterboxing (margins that keep the content area at a common size), a technique the manual credits to Mozilla in 2019. It limits font enumeration, restricts requested languages to a small set and reports standardised user agents: all Windows systems as Windows 10, all macOS as OS X 10.15, all Android as Android 10 and other systems as Linux on X11. Users cannot choose which operating system to appear as, because "any option to choose would only make users more unique". The manual also lists canvas image extraction blocking and first-party isolation. Tor Browser's design document explains the preference for uniformity: randomisation is hard to evaluate and can give a false sense of security if fingerprinters learn to ignore the noise.

Firefox's privacy.resistFingerprinting preference came out of Mozilla's Tor Uplift work. The Mozilla wiki lists among its behaviours spoofing the locale to en-US and the time zone to UTC, which is also why it can break sites that need your real time zone.

Removing or reducing values

WebKit's tracking prevention page lists several reductions in Safari: fonts limited to web and OS-bundled fonts, a user agent that does not change with minor updates, no plug-ins on macOS, a permission prompt for motion sensors on mobile, protection against fingerprinting attached cameras and microphones through WebRTC, and removal of the Do Not Track flag, which WebKit notes "ironically was used as a fingerprinting vector".

Chrome's user agent reduction is the largest example by user count. The Chromium project's page records it: Chrome 101 replaced the minor, build and patch version with 0.0.0 (100% of clients on 13 June 2022), the reduced desktop string reached 100% of Chrome 107 and later clients on 7 February 2023, and the reduced Android string reached 100% of Chrome 110 and later on 11 May 2023, with the device model replaced by "K" and the Android version by 10. A reduced desktop string from Chromium's examples:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.0.0 Safari/537.36

The detail moved into client hints that sites must request.

Randomisation

Randomisation makes each user look different to every site. Brave's May 2020 post calls its version "farbling": slightly randomising semi-identifying outputs using a random session token, regenerated at each browser start and mixed with the first-party domain. A site sees consistent values within a session but different values from other sites and in later sessions. The post described an off level, a default that adds small noise to canvas, audio and other endpoints, and a maximum level that returns fully random values and may break sites. It described work then in development, so check current settings. Safari 17.0 also added noise to fingerprintable web APIs in Private Browsing.

Blocking known fingerprinting scripts

Active fingerprinting has to run code, and list-based blocking of known fingerprinting scripts is still the most widely deployed defence. Mozilla says Firefox's Enhanced Tracking Protection has long blocked known tracking and fingerprinting scripts. Safari 17.0 blocked known trackers and fingerprinting in Private Browsing. WebKit's Safari 26.0 notes go further for known fingerprinting scripts in all browsing: they are prevented from reliably reading screen dimensions, hardware concurrency, speech synthesis voices, payment capabilities, web audio readback, 2D canvas and more, and from setting long-lived script-written storage.

Lists cannot catch a new or first-party fingerprinter. Mozilla's November 2025 post says the second phase of Firefox's defences, completed in Firefox 145, targets fingerprinters that are not on known tracker lists by hiding details such as CPU core count, touch point count and taskbar size, and by strengthening font protections. The new defences debut in Private Browsing and Enhanced Tracking Protection Strict mode. Mozilla says they "cut the percentage of users seen as unique by almost half", a figure from its own research that we could not check independently.

Privacy budgets

A privacy budget caps how much identifying information a site may read before the browser returns errors, generic values or noise. A 2019 proposal by Chrome engineers described measuring each API's entropy, tracking what each site reads and enforcing a cap, with a permission "escape valve" for applications such as games or video calls. The proposal repository was archived on 29 January 2024. In October 2025 Google announced it was retiring several Privacy Sandbox technologies, including IP Protection, while keeping CHIPS, FedCM and Private State Tokens. A general privacy budget is not a shipped feature you can rely on.

Comparing the approaches

What regulators say

This is a summary of what regulators and EU advisory bodies have published, not legal advice.

The EU ePrivacy rule: Article 5(3)

Article 5(3) of the ePrivacy Directive (2002/58/EC, as amended) allows storing information on a user's device, or reading information already stored there, only with consent or where strictly necessary for specific purposes. It is usually called the cookie rule, but its wording is not limited to cookies.

The Article 29 Working Party's Opinion 9/2014, adopted on 25 November 2014, applied the rule to device fingerprinting. It worked through use cases: fingerprinting for first-party analytics or behavioural advertising needs consent; recognising a device as an extra authentication factor is not strictly necessary and needs consent; fingerprinting for security the user explicitly requested, such as detecting repeated failed logins, can be exempt, but only if the data is never reused for another purpose.

The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3), adopted in final form (version 2.0) on 7 October 2024 after consultation on a November 2023 draft, go further. Article 5(3) applies whenever an entity "takes steps towards gaining access" to information on the device, including by sending JavaScript that instructs the browser to report back. Relying on HTTP headers (the guidelines name the accept field and user agent), caching mechanisms such as ETag, or HSTS to collect information, for example for fingerprinting, can also trigger it. In the EU, the fact that a fingerprinting script stores nothing does not take it outside the consent requirement.

GDPR: is a fingerprint personal data?

The 2014 opinion states that device fingerprints "can also constitute personal data". When a fingerprint is used to single out and track a person, even without a name, it is generally treated as personal data, and the GDPR's rules on lawful basis, transparency and data subject rights apply on top of the ePrivacy rule. The GDPR's definition of personal data in Article 4(1) lists an online identifier among the ways a person can be identified.

The UK: PECR and the ICO

In the UK the equivalent rule is regulation 6 of the Privacy and Electronic Communications Regulations (PECR). On 19 December 2024 the ICO responded to an ad platform's announcement that, from 16 February 2025, it would no longer prohibit organisations using its advertising products from fingerprinting. The ICO said fingerprinting "is not a fair means of tracking users online" because it reduces people's choice and control, called the change irresponsible, and said it will act where fingerprinting is not deployed lawfully and transparently. It added that meeting data protection law when fingerprinting for advertising is a high bar.

The ICO published draft guidance on storage and access technologies on 20 December 2024, updated it for the Data (Use and Access) Act, and finalised it on 29 April 2026. Its section on device fingerprinting says regulation 6 applies wherever fingerprinting stores or accesses information on a device, and lists device configuration data, network protocol data, CSS information, JavaScript objects and HTTP header information as examples. Even its example of fingerprinting to detect fraudulent account creation is marked "Regulation 6 applies".

That does not always mean consent. The guidance lists five exceptions: communication, strictly necessary, statistical purposes, appearance and emergency assistance. Its examples of strictly necessary activities include securing terminal equipment and preventing or detecting fraud. It is equally clear that no advertising purpose meets the strictly necessary exception, judged from the user's point of view.

For users, the law is a reason to expect consent requests and a basis for complaints; it does not make fingerprinting technically harder. For site owners, fingerprinting for advertising or analytics is treated like a tracking cookie, and fingerprinting for fraud prevention needs a documented, narrow purpose with no secondary use.

What actually reduces your fingerprint

One principle covers everything here: look like many other people, or look different every time, but never like a rare, stable combination. Changing one value by hand usually does the opposite.

Choose a browser category, not a list of tweaks

• Crowd-uniform browsers. All users of a version report the same values, which gives the largest anonymity set at the cost of some breakage. EFF's Cover Your Tracks pages describe this as the most realistic protection currently available.
• Randomising browsers. Outputs are varied per site and per session so that cross-site linking fails while sites keep working.
• Mainstream browsers with protections switched on. Firefox and Safari document stronger protections in private or strict modes, and Safari 26 restricts known fingerprinting scripts in normal browsing. Chrome's reduced user agent shrinks passive exposure for everyone, but EFF notes that Chrome's Incognito mode does not protect against trackers or fingerprinters.

Within any category, keep the defaults. Defaults are where the crowd is: the browser's own language and zoom settings, a common window size (or letterboxing where offered), no extra system fonts installed on a whim, and an up to date build, since outdated versions stand out.

Be careful with extensions

EFF warns that your protections can themselves become part of your fingerprint, turning you into the one visitor with a very particular set of privacy tools. A tracker blocker still helps, because a script that never loads cannot fingerprint you. The risk comes from stacking extensions, especially ones that modify pages or spoof values. EFF's example is a Safari user who swaps in a Chrome user agent and becomes "the only browser out there identifying itself as Chrome but looking like Safari". One tracker blocker, or the browser's built-in protection, is usually better than five. Disabling JavaScript removes most active fingerprinting, but it breaks much of the web and makes most sense inside a browser built for it, where many other users do the same.

What does not reduce your fingerprint

• Clearing cookies. It resets cookies, not fingerprints.
• A VPN on its own. It changes your IP address, not your fonts, canvas output, screen or time zone.
• Private browsing everywhere. Private modes were built to avoid local traces. Safari (since 17) and Firefox add fingerprinting protection in private mode; EFF notes Chrome's Incognito does not.
• Do Not Track. Most sites ignored it, and WebKit removed it partly because it made users more unique.

If being linked across sites is a physical safety issue for you, assume the W3C's strongest threat model, where the adversary may be a state. Use a browser built for anonymity in its default configuration, do not log in to personal accounts in the same session, and do not resize or customise it.

Step by step: test your own browser and compare settings

You do not need special tools. Two public research sites and your browser's developer console are enough. Write your results down so you can compare.

Step 1: record a baseline

1. Open Cover Your Tracks in your everyday browser and run the test. Note two numbers: the bits of identifying information and the "one in X browsers" figure. Note whether it says your fingerprint is unique, and whether it detects randomisation.
2. Open AmIUnique and view your fingerprint. Note the overall uniqueness result and which attributes it flags as rare.
3. Note the browser version, operating system, window state (maximised or not), extensions and whether you were in a private window.

Both sites compare you against their own, more privacy-minded visitors, so treat the numbers as relative, not absolute.

Step 2: see what you send passively

Your browser sends headers before any script runs. Save the following as echo_headers.py and run it locally. It only prints the headers your own browser sends to your own machine.

# echo_headers.py: print the request headers your browser sends to localhost
from http.server import BaseHTTPRequestHandler, HTTPServer

class EchoHeaders(BaseHTTPRequestHandler):
    def do_GET(self):
        lines = [f"{name}: {value}" for name, value in self.headers.items()]
        body = "\n".join(lines).encode("utf-8")
        self.send_response(200)
        self.send_header("Content-Type", "text/plain; charset=utf-8")
        # Ask for two high entropy client hints so the next reload shows them
        self.send_header("Accept-CH", "Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List")
        self.end_headers()
        self.wfile.write(body)

HTTPServer(("127.0.0.1", 8000), EchoHeaders).serve_forever()

python3 echo_headers.py
# then open http://127.0.0.1:8000 in the browser you are testing, and reload once

Look at User-Agent, Accept-Language and, in browsers that implement client hints, the Sec-CH-UA, Sec-CH-UA-Mobile and Sec-CH-UA-Platform headers. After the reload, a supporting browser may add the two high entropy hints the server asked for. Seeing them appear only after the server's Accept-CH request is the client hints model in action. If you see no Sec-CH-UA headers at all, your browser does not implement them; MDN marks the JavaScript side of the API as limited availability and secure context only.

Step 3: see what a script can read

Open the developer console (F12 or Cmd+Option+I) on any page and paste this read-only snippet. It reads a handful of common values and prints them; it does not hash or send anything.

// Read-only: print a few commonly fingerprinted values from your own browser
const info = {
  userAgent: navigator.userAgent,
  languages: navigator.languages,
  timeZone: Intl.DateTimeFormat().resolvedOptions().timeZone,
  screen: `${screen.width}x${screen.height} @${window.devicePixelRatio}`,
  available: `${screen.availWidth}x${screen.availHeight}`,
  window: `${window.innerWidth}x${window.innerHeight}`,
  cores: navigator.hardwareConcurrency,
  touchPoints: navigator.maxTouchPoints,
};
console.table(info);
if (navigator.userAgentData) {
  navigator.userAgentData
    .getHighEntropyValues(["platformVersion", "architecture", "model", "fullVersionList"])
    .then((v) => console.log("High entropy client hints:", v));
}

Compare screen and available: the difference is your taskbar or dock. Compare the time zone with where you actually are. Note the core count.

Step 4: repeat in a clean profile

A fresh profile stops extensions and history from skewing the result. Delete the throwaway directory afterwards.

# Chrome or Chromium on Linux: a temporary profile
google-chrome --user-data-dir="$(mktemp -d)"

# Chrome on macOS: a temporary profile
open -na "Google Chrome" --args --user-data-dir="$(mktemp -d)"

# Firefox on any OS: open the profile manager to create a test profile
firefox -P -no-remote

Run steps 1 to 3 again in the clean profile and record the results.

Step 5: repeat with each protection setting

Run the same tests in a private window, in the browser's strictest built-in tracking protection mode, in a crowd-uniform browser left at the window size it opens with, and in a randomising browser. In Firefox, the privacy.resistFingerprinting preference in about:config turns on the uniformity behaviour described earlier; try it only in the test profile, because it changes your reported time zone and locale.

Step 6: test stability and extensions

Run the test twice, restart the browser and run it again. A randomising browser should show different canvas or audio values between sessions, a uniform browser the same common values, and an unprotected browser the same rare values every time. The last case is the one to worry about. Then, in the clean profile, add one extension at a time and note whether your bits of identifying information go up or down. Remove extensions that add bits without blocking anything you care about.

A results template

Comparison: tracking techniques side by side

Fingerprinting on your own sites

If your organisation runs a public site, it may already fingerprint visitors without anyone deciding to, through an analytics library, an A/B testing tool, a fraud prevention SDK or a tag manager. Under the EDPB and ICO positions, that is your compliance question, not only the script vendor's. A practical review: inventory every client-side script and library your pages load, both bundled at build time and injected at runtime; check each one's documentation for device recognition; map each use to security and fraud prevention, analytics or advertising; and put everything outside a narrow security purpose behind consent and in your privacy notice. The build-time half of that inventory is the list of npm packages in your front-end bundle.

Common mistakes

• Treating cookie consent as covering fingerprinting by default. If your consent banner only talks about cookies and a script fingerprints visitors regardless of the answer, the EDPB and ICO positions above say you have a problem.
• Spoofing one value. Changing the user agent, time zone or screen size by hand creates a combination no real browser has. EFF and the Tor Browser manual both warn against it.
• Stacking privacy extensions. Each one can be detected. A rare set of extensions is itself a fingerprint.
• Assuming a VPN hides your browser. It hides your IP address. Your fingerprint travels through the VPN unchanged.
• Reading one test score as absolute truth. Test sites compare you with their own unusual visitors. Use scores to compare configurations.
• Resizing a uniformity browser. Maximising changes the window size that letterboxing protects.
• Protecting one device only. Your phone, work laptop and tablet each have their own fingerprint.
• For site owners: assuming fraud prevention means no rules apply. The ICO's fraud detection example is within regulation 6. It may fit an exception, but only with a documented, narrow purpose and no secondary use.

FAQ

Can websites track me without cookies?

Yes. A site can compute an identifier from your browser's configuration (user agent, screen, fonts, time zone, graphics output) without storing anything. Combined with your IP address, that is often enough to recognise a returning browser and to link visits across sites that embed the same third-party script.

Does incognito or private mode stop browser fingerprinting?

Not by itself. Private modes were built to avoid leaving local history. Safari has added fingerprinting protections to Private Browsing since Safari 17, and Mozilla says its newest protections debut in Firefox's Private Browsing and strict mode. EFF notes that Chrome's Incognito mode does not protect against fingerprinters.

Does a VPN prevent browser fingerprinting?

No. A VPN changes your IP address. Your fonts, screen, canvas output and time zone stay the same on every VPN server.

How accurate is browser fingerprinting?

It depends on the audience. Studies of privacy-minded volunteers found 83.6% (2010) and 89.4% (2016) of browsers unique; a 2018 study of about 2.07 million fingerprints from a mainstream French website found 33.6% unique. Trackers combine fingerprints with IP address and behaviour, which raises accuracy.

Is browser fingerprinting legal?

In the EU, the Article 29 Working Party (2014) and the EDPB (2024) place it under the ePrivacy consent rule unless an exemption such as user-requested security applies. In the UK, the ICO says PECR regulation 6 applies and that fingerprinting for advertising faces a high bar. Rules elsewhere differ.

What is canvas fingerprinting?

A script draws text and shapes into an invisible canvas, reads the pixels back and hashes them. The result varies with your GPU, driver and font rendering. Browsers counter it by blocking readback for known fingerprinting scripts or adding small amounts of noise.

Which browser is best against fingerprinting?

We do not rank browsers. The categories are browsers that make every user look the same, browsers that randomise values per site and session, and mainstream browsers with protections in private or strict modes. Pick the category that fits your threat model and keep its defaults.

Do privacy extensions make fingerprinting worse?

They can. A tracker blocker helps because scripts that never load read nothing, but each extension can be detected, and an unusual combination makes you more unique.

How do I check my browser fingerprint?

Use EFF's Cover Your Tracks and AmIUnique, then compare results across a clean profile, a private window and stricter settings. The step by step section above shows how, including a local script that prints the headers you send.

What are User-Agent Client Hints?

A draft W3C community specification that replaces the detailed User-Agent string with small headers. By default only brand, mobile flag and platform are sent; a site must ask with Accept-CH for more, which makes collection visible and lets the browser decide what to answer.

Where Safeguard fits

Safeguard does not block trackers, measure browser fingerprints, or tell you whether a script is a fingerprinter, and nothing in the user advice above depends on it. The fit is indirect and sits on the site owner's side. Fingerprinting code reaches websites as software: analytics, testing and fraud prevention libraries that are often installed from npm and bundled into the front end. Safeguard scans repositories, container images and SBOM files and builds an inventory of the components they contain, so you can see which client-side packages and versions actually ship in each project, which feeds step 1 of the review above. Safeguard matches those components against vulnerability databases. It cannot see scripts that a tag manager injects at runtime from someone else's server, so that half of the inventory still has to come from your tag configuration.

Fix it without waiting for upstream

The analytics, consent, testing and fraud prevention libraries that sit in your front-end bundle are open source dependencies like any other, and when one of them has a published vulnerability it needs the same treatment as the rest of your supply chain. The fit with fingerprinting itself is indirect, but keeping the scripts you choose to ship patched and inventoried is part of running a site honestly; the fork and patch route described below is early access.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It asks the assistant to fix a lodash CVE in a repository, reads the finding and advisory, asks before each command, edits package.json to a fixed version, and runs npm install and npm test with approval, pushing nothing. The same flow applies when a scan of your website's repository shows an outdated analytics or consent library in the front-end bundle: you ask for the upgrade and approve each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and then scans from the terminal. It suits a web team that wants an inventory of the client-side packages each site ships before a privacy review, without sending source anywhere first.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is useful when you want to ask an assistant which of your projects carry a given front-end library version while you work through the script inventory described above.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• W3C Privacy Working Group: Mitigating Browser Fingerprinting in Web Specifications (editor's draft)
• W3C WICG: User-Agent Client Hints (draft community group report)
• MDN: Navigator.userAgentData
• Chromium: User-Agent Reduction
• Privacy Sandbox: Update on plans for Privacy Sandbox technologies (17 October 2025)
• Combating Fingerprinting with a Privacy Budget (archived proposal repository)
• Peter Eckersley, How Unique Is Your Web Browser? (PETS 2010)
• Laperdrix, Rudametkin, Baudry, Beauty and the Beast: Diverting modern web browsers to build unique browser fingerprints (IEEE S&P 2016)
• Gómez-Boix, Laperdrix, Baudry, Hiding in the Crowd: an Analysis of the Effectiveness of Browser Fingerprinting at Large Scale (WWW 2018)
• EFF Cover Your Tracks: About and methodology
• EFF Cover Your Tracks: Learn
• AmIUnique
• Tor Browser manual: Fingerprinting protections
• The Design and Implementation of the Tor Browser
• Mozilla wiki: Security/Fingerprinting
• Mozilla blog: Firefox expands fingerprint protections (10 November 2025)
• WebKit: Tracking Prevention in WebKit
• WebKit: WebKit features in Safari 17.0
• WebKit: WebKit features in Safari 26.0
• Brave: Fingerprinting defenses 2.0 (May 2020)
• Article 29 Working Party: Opinion 9/2014 on the application of Directive 2002/58/EC to device fingerprinting
• EDPB: Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive, version 2.0
• EDPB: Guidelines 2/2023 consultation page
• ICO: Our response to Google's policy change on fingerprinting (19 December 2024)
• ICO: Guidance on the use of storage and access technologies
• ICO: What are storage and access technologies?
• ICO: What are the exceptions?

Related reading: private search engines and browsers compared, how to de-Google an Android phone safely, how AI agent web search leaks your data to search engines, Google Maps alternatives and how to switch and self-hosting photos, files and calendar.

Last reviewed: 23 October 2026. Browser protections change with every release; check the documentation linked above for the version you run.