← All articles

What Makes a Fingerprint Consistent?

2026-08-07 · 6 min read

A consistent fingerprint describes one device that could physically exist, and reports the same values every time it returns. Consistency has two halves: internal agreement between fields at a single moment, and stability of those fields across visits. Failing either half is what gets a profile flagged, not the act of spoofing itself.

Which fields have to agree with each other?

Fingerprint fields are not independent. Declaring an operating system implies a font set, a set of plausible GPU strings, a plausible screen size, and a particular TLS handshake shape. Detection systems check these implications rather than trusting declarations, so agreement across the five groups below matters more than the value of any single field.

Group	Fields	Must agree with
Platform	User-Agent, Client Hints, navigator.platform	Each other
Hardware	GPU renderer, CPU cores, device memory	Device class
Display	Screen size, viewport, pixel ratio	Device class
Locale	Timezone, language, number formatting	IP geolocation
Rendering	Canvas, WebGL, audio, fonts	Platform + hardware

A phone user agent with 16 CPU cores and a 2560-pixel viewport fails the hardware and display groups simultaneously. No production device matches that combination, so the profile is anomalous before any behaviour is observed.

Why does stability matter as much as agreement?

Fingerprint systems store what they saw last time. A returning visitor whose canvas hash, font list and screen size all changed since yesterday is a stronger anomaly than one whose values stayed identical, because real hardware changes slowly. A laptop might gain a font after a software update; it does not swap GPU vendors overnight.

The same applies within a session. Two page loads 30 seconds apart must return identical canvas and audio hashes, since the same GPU and audio stack produced both. Tools that inject fresh noise per call break this and create a signature that dedicated tests look for directly.

What does the locale group actually check?

Locale is the group most often left at defaults, and it is the easiest to verify from the server side. A request arriving from a German IP while the browser reports a US timezone and English number formatting is a mismatch the platform can evaluate without any client-side script at all.

Field	Should follow	Typical default failure
Timezone	IP geolocation	Left at the host machine's zone
Accept-Language	Country of the IP	en-US everywhere
Geolocation API	IP geolocation	Denied, or true coordinates
Number and date format	Locale	Mismatched with language

Which inconsistency costs the most?

Timezone against IP, by a wide margin. Checking it requires no client-side script and no fingerprinting library — the server already knows the IP country, and the browser volunteers the timezone in 1 line of JavaScript. That makes it the cheapest check any platform can run and the first one most of them run.

Second place goes to WebRTC exposing the real address behind a proxy, because it reveals 2 network paths where a real device has 1. Between them, those 2 mistakes account for most profiles that fail on their first serious login attempt.

How do you verify a profile is consistent?

Run a two-part test that takes about 10 minutes. First, open the profile on a fingerprint test page and confirm the five groups agree — platform matches fonts, hardware matches device class, locale matches IP. Second, reload the page and confirm canvas, WebGL, audio and font values are byte-identical to the first load.

Repeat the second half after any browser update, because a version bump can change rendering output and silently alter a profile that platforms had already learned. Treat a value that differs between two consecutive reloads as a defect, and treat a profile whose values drifted after an update as a new device that needs re-establishing rather than one that can resume its old sessions.

Budget about 10 minutes per profile at creation and 2 minutes after each update. Across 20 profiles that is roughly 3 hours of setup once, against the alternative of discovering the same defect 20 times through 20 separate account reviews.