Device fingerprinting: how it works in browsers and mobile apps

How a browser fingerprint is built

A browser exposes dozens of properties to any page it loads. Each one alone is shared by millions of people, but together they narrow a browser down to a small group or a single device. A fingerprinting script collects these signals and turns them into an identifier.

Common signals are canvas and WebGL rendering output, installed fonts, audio processing output, screen size and colour depth, hardware concurrency and memory, time zone, languages, speech voices and media capabilities.

• Rendering signals: canvas, WebGL renderer and extensions.
• Environment signals: time zone, languages, screen, platform.
• Capability signals: fonts, voices, codecs, WebRTC support.
• Network context: IP address, ASN, datacenter or Tor exit, checked against the time zone.

Browser fingerprinting in detail →

Device fingerprinting in mobile apps

Native apps have better tools than a browser. On Android and iOS an SDK can read platform identifiers and ask the operating system to attest that the app is genuine: Play Integrity on Android, App Attest and DeviceCheck on Apple platforms. The identifier gives the identity; the attestation tells the server whether to trust it.

Why the matching has to happen on the server

If the browser computes its own ID and sends it to your backend, an abuser can send any ID they like. A robust fingerprint only collects raw signals on the client. The server normalises and hashes them, matches them against devices it has seen before and scores how much the request can be trusted.

Matching must also be fuzzy. Browsers update, fonts get installed, a window is resized. Exact hashing gives a returning visitor a new ID after small changes; weighted, per-signal similarity keeps the same identity while still separating different devices.

How accurate is device fingerprinting?

Accuracy depends on how many independent signals are collected, whether matching tolerates change, and whether the result is combined with other evidence. Identical models of the same phone share most signals, so a good system treats such shared device classes more carefully, for example by asking for a human check on every claim.

For abuse prevention the identifier is one input. Pair it with email normalisation, per-network limits and a human check for first claims, and the remaining false positives can be resolved with a Turnstile challenge instead of a hard deny.

Device fingerprinting and privacy

Fingerprinting for security and fraud prevention is commonly based on legitimate interest under GDPR, provided it is limited to that purpose, disclosed in your privacy notice and not reused for advertising. Store hashes instead of raw values, keep retention short and delete a user's data on request.

What a device fingerprinting API should return

A visitor ID alone leaves the hard work to you. When comparing APIs, look for:

• A stable ID across private windows, cleared cookies and browser updates.
• A separate trust score with reasons, so a bot or a tampered browser is not treated like a person.
• A signed result your backend can verify, so the browser cannot swap in another ID.
• The same ID model in mobile apps, backed by platform attestation.
• Decisions, not just data: whether this device may claim a trial or coupon, or use a free feature again.

Using device fingerprinting with FingerPrint Checker

FingerPrint Checker collects signals in the browser or the Android, iOS and macOS SDKs, seals the upload and does all hashing, fuzzy matching and scoring on the server. Your backend then asks one question, such as whether this device may claim a free trial, and receives allow, deny, or a human check to show first (Turnstile or proof-of-work). Every account starts with 2,000 free checks.

Frequently asked questions