How browser fingerprinting works
Every time a browser requests a page, it sends headers such as its user agent and preferred language. Once the page loads, JavaScript can read many more values: screen resolution, color depth, number of CPU cores, supported media formats, installed fonts and whether certain features exist. A script can also ask the browser to draw hidden text or shapes and measure the exact output.
Those values are combined into a fingerprint. On their own, most values are shared by many people. Together, they narrow the crowd down sharply. Researchers at the Electronic Frontier Foundation showed this with their Panopticlick project, later renamed Cover Your Tracks, which lets anyone test how unique their own browser looks.
What a browser fingerprint typically includes
| Signal | Example | How stable it is |
|---|---|---|
| User agent and client hints | Chrome on Windows | Changes with every browser update |
| Screen | Resolution, pixel ratio, color depth | Stable unless the monitor changes |
| Locale | Language list, timezone | Stable, but easy to fake |
| Fonts | Which fonts are installed | Fairly stable per machine |
| Rendering | Canvas, 3D graphics and audio output | Stable per hardware and driver |
| Features | Supported codecs, APIs, storage limits | Changes with browser version |
Browser fingerprinting vs cookies
Cookies
- An ID stored on the device by the site
- Deleted by clearing browser data or private mode
- Blocked or limited for third parties by most browsers
- Exact: the same cookie means the same browser
Browser fingerprint
- Computed from traits, nothing stored
- Survives clearing cookies and private mode
- Weakened by browser privacy features and spoofing
- Probabilistic: similar traits suggest the same browser
Why it matters in fraud prevention
For a fraud team, a browser fingerprint answers a simple question: have we seen this browser before, and with which accounts? A fraudster who clears cookies between signups still shows the same fingerprint. That is why fraud tools target it directly. Antidetect browsers give each profile invented values, headless browsers used by bots try to mimic a normal desktop, and some tools randomize values on every load.
A browser fingerprint is also narrower than a device fingerprint: switch from Chrome to Firefox on the same laptop and most browser values change. For linking accounts, both views are useful.
On the defense side, the most useful question is not "is this fingerprint unique?" but "is this fingerprint honest?" A real Safari on an iPhone exposes a predictable set of features, fonts and rendering quirks. When a visitor claims to be that iPhone but supports features only desktop Chrome has, or reports a screen size no iPhone ships with, the mismatch says more than any single value. Consistency checks like these also help with bots that copy a real user agent string but run in a server environment.
How to make browser fingerprinting hold up
The fix is to stop trusting what the browser says about itself. Check whether the claimed browser version really supports the features it reports, whether its rendering matches the claimed hardware, and whether its network fits its stated location. Kavra runs these checks across layers on every visit and flags spoofed or rotating fingerprints. Learn how in fingerprint spoofing and rotation.
Good fingerprinting also respects the people it describes. Collect only what is needed to recognize devices and spot tools, honor consent choices, and never use the fingerprint itself as the identifier stored in your systems. A random, opaque visitor ID tied to the evidence is safer and easier to erase on request.