Browser fingerprinting is the practice of collecting the small details a browser reveals during a normal visit and combining them into an identifier that can recognise that browser again. Nothing has to be stored on the device, so the identifier can persist after cookies are cleared or a private window is used. The EFF's Cover Your Tracks describes it as tracking browsers by the configuration and settings information they make visible to websites. The technique sits inside the wider category of device fingerprinting, and it is the background for the tools in the antidetect browsers overview, which work with these same signals from the side of the user.
What browser fingerprinting is
A page can only load correctly if the browser tells the server certain things: what it can display, in which language and in what format. Fingerprinting gathers those details, and others that scripts can read, and processes them into a compact identifier, often called a digital fingerprint. The difference from a cookie is where the data lives. A cookie is an identifier a site places in the browser, and the user can delete it. A fingerprint is computed from what the browser already exposes, so clearing storage does not reset it. Cover Your Tracks makes the same point: deleting cookies will not help, because the characteristics of the browser configuration are what is analysed.
Device fingerprinting is the broader concept: recognising a device regardless of the client used, which is common in mobile apps. Browser fingerprinting is the subset that relies on what a web browser exposes, and canvas fingerprinting is one technique inside it.
Passive and active collection
The W3C's guidance on mitigating browser fingerprinting separates two modes. Passive fingerprinting is based on characteristics observable in the contents of web requests, without any code executed on the client. Active fingerprinting adds techniques where a site runs JavaScript or other code on the client to observe further characteristics of the browser, user, device or context. The document notes that active fingerprinting is potentially detectable on the client, whereas passive collection is harder to notice and control.
What signals exist
| Signal | What it reveals | How consistent it is expected to be with the others |
|---|---|---|
| IP address | Network location and the organisation providing the connection | Usually fits the language and time zone of the visitor |
| User-Agent | Browser, version, engine and operating system | Should match the platform reported by other signals |
| Accept headers | Supported formats, preferred languages, compression support | Order and content reflect the browser engine |
| Client Hints | Browser brand, platform, and gated details such as model or memory | Should agree with the User-Agent |
| Screen size and colour depth | Display dimensions and capability | Changes with a monitor or resolution change |
| Language | Interface language and locale formats | Typically fits the Accept-Language header |
| Time zone | Offset from UTC and zone name | Stable for a device unless the clock or location changes |
| Platform and hardware hints | Operating system string, logical processor count, approximate memory | Rarely changes; unusual values single a device out |
| Fonts | The set of fonts available to the page | Rarely changes |
| Canvas | How the browser renders a hidden 2D drawing | Depends on graphics stack, drivers and fonts |
| WebGL | Graphics vendor and renderer, plus rendering parameters | Tied to the graphics hardware and driver |
| Audio | How the device processes a generated signal | Determined by browser, operating system and hardware |
| Media devices | The number and type of cameras, microphones and speakers | Changes when peripherals are connected |
| Connection details | How the secure connection is negotiated | Set by the client software, below the page |
User-Agent Client Hints illustrate a design response: low-entropy hints such as browser brand and platform may be sent by default, while high-entropy hints with greater fingerprinting potential are gated, and the browser decides whether to share them based on user preferences, permission requests and policies.
How an identifier is built
- A script runs when a visitor lands on a page, or the server reads what arrives with the request.
- Passive signals from the request and active signals queried through browser interfaces are collected.
- The values are combined into a single structure.
- The structure is converted into a hash, a compact string representing the whole profile.
- The hash is stored server-side and compared with the one seen on earlier visits.
Because the combination is what matters, a system weighs each signal by how distinctive and how durable it is. Fingerprints change over time as browsers are updated and hardware changes, so a fingerprint supports a risk decision rather than proving identity. Uniqueness and stability pull against each other: a signal that changes often is a poor identifier, and a signal shared by very many users adds little.
Fingerprinting compared with cookies and other storage
Cookies, LocalStorage and SessionStorage keep an identifier on the device. The user can clear them, they are scoped to a domain, and SessionStorage lasts only for a tab or session. Some techniques duplicate an identifier across several storage mechanisms. ETag tracking uses the HTTP cache: the server returns a resource with a unique ETag header, the browser sends the value back on later requests, and the server can recognise the visitor without JavaScript. CNAME cloaking presents a third-party tracker under a subdomain of the site, so blockers that look for third-party domains do not see it. Fingerprinting differs because it needs no stored identifier.
Techniques behind the signals
Several methods feed a fingerprint, and most systems combine more than one.
Canvas fingerprinting asks the browser to draw an image, often with text, and hashes the result; differences in hardware, drivers and fonts make the output vary between devices. WebGL does the same for 3D rendering. MDN documents that the WebGL debug renderer extension exposes the graphics driver's unmasked vendor and renderer strings, that it may be available only in privileged contexts or not at all depending on privacy settings, and that it is intended for debugging rather than general use, as the MDN page on WEBGL_debug_renderer_info explains. Audio fingerprinting passes a generated signal through the browser's audio processing and measures the result; no sound is played or recorded. Font detection infers which fonts are installed from how text renders. Media device enumeration lists connected cameras and microphones, and a fuller list requires permission.
Screen properties and language settings add dimensions and locale. WebRTC can reveal network adapter information without a permission prompt, and CSS-based methods use stylesheet rules that trigger different requests depending on device properties, which works even when JavaScript is blocked. At the connection level, the parameters a client offers when it negotiates a secure connection vary between software and can be observed by the server without any script running. Research also explores side channels such as cache and processor behaviour; this work is largely experimental.
Why sites use fingerprinting
The same signals serve different purposes.
Fraud prevention and security. A fingerprint helps recognise a returning device even when cookies or the address change. If a user's fingerprint normally stays the same and one day location and device type differ completely, the mismatch can trigger extra verification. Repetitive login attempts and credential-stuffing patterns can be caught by comparing them with stored profiles, and fraud teams look at whether many accounts share a configuration. Because fingerprints change and can be shared by many users, they are treated as one input to a risk decision. This is also how CPA networks use fraud detection: the signals that flag a suspicious login help a network judge whether a conversion is genuine.
Analytics, personalisation and advertising. Recognising a returning visitor can reduce friction, for example fewer authentication steps for someone already known to be valid. It also supports measurement, localisation and ad targeting, which is where privacy concerns are strongest.
Privacy concerns and regulation
A fingerprint is harder to reset than a cookie, so tracking can continue when storage is cleared, and it happens without visible signs, since fingerprinting scripts look like any other script. The legal picture is uneven: rules on disclosure and consent differ by jurisdiction and by use, and security uses are generally treated differently from personalisation or advertising. Anyone deploying it should check the requirements for their own case.
Browser and regulatory countermeasures
Browser makers and standards bodies work on the problem at several levels. The W3C guidance lists design practices for specification authors, among them limiting the surface of new features, minimising the entropy that APIs expose, standardising non-functional differences, requiring opt-in for sensitive data, and avoiding new persistent identifiers.
Browsers apply them differently. WebKit's tracking prevention page states that it examines new features for fingerprinting risk, restricts font availability to web fonts and fonts that come with the operating system rather than user-installed ones, requires permission for device orientation and motion data, and declines to implement some interfaces because of fingerprinting concerns. Firefox disables the WebGL debug renderer extension when its resist-fingerprinting preference is on, according to the MDN page cited above. Tools that add noise or block interfaces have a side effect: an unusual configuration can itself be distinctive, and it can trigger extra checks such as CAPTCHAs on some sites. The consensus of the guidance cited here is that fingerprinting is hard to detect and hard to prevent, and countermeasures reduce exposure rather than remove it.
What this means for people who manage several legitimate profiles
People who use more than one browser profile for testing, quality assurance, ad verification or accounts they are authorised to manage meet the same signals. Each profile has its own User-Agent, screen values, fonts, rendering output and network address, and a profile whose values contradict one another is a poor test environment. How antidetect browsers handle these signals is about keeping each working environment separate and coherent for legitimate tasks, and how the IP address relates to the rest of the fingerprint explains the network side.
Fingerprinting exists partly to enforce platform rules, and platform terms apply to every profile. A configuration that violates a platform's rules can lead to restrictions regardless of how the browser is set up.
FAQ
Is browser fingerprinting the same as cookies?
No. A cookie stores an identifier on the device, which the user can delete or block. A fingerprint is computed from what the browser already exposes and held on the server, so clearing cookies does not remove it. Many systems use both and fall back on the fingerprint when cookies are unavailable.
Does incognito mode stop fingerprinting?
No. Private browsing hides local history and storage, not the characteristics of the browser and device. The EFF states that deleting cookies does not help against fingerprinting, because the configuration is what is analysed.
What is the difference between passive and active fingerprinting?
Passive fingerprinting uses only what is observable in web requests, without code running on the client. Active fingerprinting runs JavaScript or other code on the client to observe additional characteristics. The W3C notes that active collection is potentially detectable on the client while passive collection generally is not.
Is browser fingerprinting legal?
It depends on the use and the jurisdiction. Security uses such as fraud detection are generally treated differently from personalisation or advertising, and disclosure or consent obligations vary. Anyone deploying it should review the requirements that apply to their case.