Browser fingerprinting combines multiple browser-exposed attributes to help distinguish one browsing environment from others. It does not require a single magical identifier, and a local fingerprint hash does not prove that a person is unique or identified.
MDN's privacy guide describes fingerprinting as collecting data points that can differentiate users. The important word is combination: a screen size, language, or rendering result may be common alone but more distinguishing when joined with other signals and observed over time.
Common fingerprint inputs
Websites can observe different groups of signals, subject to browser policy and user settings:
- Browser identity: User Agent tokens, feature support, preferred languages, and platform hints.
- Display and rendering: screen dimensions, color depth, Canvas output, WebGL vendor/renderer information, and layout measurements.
- Audio and fonts: deterministic audio processing output and whether selected fonts appear available.
- Network context: the request address seen by a server and, in some WebRTC configurations, ICE candidate addresses.
- Behavior and state: timing patterns, stored identifiers, permissions, and site-specific state can supplement passive attributes.
This list changes as browsers add protections and web APIs evolve. For example, User-Agent reduction removes or generalizes some operating-system, device-model, and minor-version detail in supporting browsers.
What the BrowserCheck test does
The BrowserCheck fingerprint test demonstrates a bounded set of locally readable surfaces:
- It draws fixed text and shapes to a Canvas element, then hashes the output in the page.
- It reads available WebGL renderer information and selected capabilities, then hashes the result.
- It computes an OfflineAudioContext sample when the API is available.
- It measures fixed Client Rects content and checks a fixed list of fonts.
- It displays browser, language, screen, and related context separately.
The hashes are compact labels for values produced in this session. BrowserCheck does not upload raw fingerprint hashes through its analytics events, and the test does not maintain a population database.
What a hash can and cannot tell you
| Observation | Supported interpretation | Unsupported interpretation |
|---|---|---|
| A hash is readable | The browser exposed a repeatable value in this session | You are unique on the internet |
| A hash changes | At least one input or browser defense changed | Tracking is now impossible |
| A hash stays the same | This particular output stayed stable across the compared runs | A site can identify your legal identity |
| A signal is unavailable | The API was blocked, unsupported, failed, or not tested | The browser passed a universal privacy test |
Estimating uniqueness requires a clearly defined comparison population, collection period, sampling method, and treatment of changing values. BrowserCheck does not collect that dataset, so it does not display a uniqueness percentage.
How browsers reduce fingerprinting
Different browsers use different strategies, and those strategies can change:
- Tor Browser standardizes or limits values such as window size, User Agent details, languages, and fonts so users fall into fewer distinguishable groups. The Tor Project advises keeping defaults and discourages extra extensions that could make a setup stand out.
- Brave describes its current standard protection as applying randomization to several fingerprintable APIs while balancing compatibility. This is not the same as Tor network anonymity.
- Firefox combines tracking protection and cookie isolation with fingerprinting protections. Exact behavior depends on version and selected settings.
No defense makes every user identical across every API and every website. Privacy features can also create compatibility costs, which is why browsers make different trade-offs.
Practical steps that do not overpromise
- Keep the browser updated through its built-in update mechanism.
- Prefer documented, built-in privacy settings before adding many extensions.
- Remove extensions you do not need. An extension can add code, permissions, and unusual behavior even when marketed for privacy.
- Compare the same test before and after one controlled setting change. Record browser version, test time, and which setting changed.
- If your threat model requires anonymity rather than ordinary tracker reduction, evaluate a purpose-built system such as Tor Browser using its official guidance.
Use the privacy report to inspect a broader set of observable values, but do not treat either page as proof of anonymity, malware safety, or protection from account-based identification.
Sources and review notes
- Privacy on the web — MDN
- Fingerprinting glossary — MDN
- User-Agent reduction — MDN
- Fingerprinting protections — Tor Project
- Brave fingerprinting protection update
- Firefox privacy and security features — Mozilla Support
Review method: claims were checked against current browser-vendor documentation and the BrowserCheck implementation. Product-specific behavior should be rechecked after major browser releases. Last reviewed August 30, 2026.