Device fingerprinting recognises a device from characteristics it already exposes, such as properties of its browser and operating system, instead of an identifier stored on it. Browser fingerprinting is the same idea for a web browser. The result is a stable identifier for the device, which Fingerly calls the visitor ID.
Developers use it where a cookie is not enough: spotting a returning device after its storage was cleared, limiting accounts or redemptions per device, and noticing when one device suddenly looks like many. It supports fraud prevention, and it is evidence for your own rules rather than a verdict.
How device fingerprinting works
- A script or SDK on the device reads characteristics within a short time budget. Nothing is asked of the visitor.
- The characteristics go to a server, which compares them with what it has seen before.
- The server answers with an identifier, and how sure it is of the match. The same device gets the same identifier on its next visit.
Because the identifier is worked out from the device rather than read back from storage, clearing cookies or storage does not on its own make a returning device look new.
How a Fingerly visitor ID relates to a fingerprint
A Fingerly visitor ID is the identifier the server resolves for a device. It is twenty letters and digits, issued by Fingerly and never derived from the device's data, so the ID itself reveals nothing about the device. It is scoped to your organization: the same device on another customer's site has a different one.
visitor_idis the identifier, andvisitor_confidence, from 0 to 100, says how the ID was reached.visitor_is_newtells you whether your organization has seen the device before.identifiable: falsemeans the device gave too little to identify anyone. It gets a fresh visitor ID, is still scored, and is free.
Fingerly goes further than an identifier. The same identification returns a suspect score and, to your backend, the signals behind it, so you also learn how suspicious the session looks.
Web and native apps
Fingerprinting a browser and recognising an app are not the same, and Fingerly treats them differently.
| Where | What recognises the device | After cookies or storage are cleared | After a reinstall |
|---|---|---|---|
| Browser (JavaScript SDK and framework bindings) | The server resolves the visitor ID from the signals the SDK sends. The SDK sets no cookies and keeps nothing in the browser. | The same device keeps its visitor ID. | Not applicable. |
| iOS (Swift SDK) | A random install ID the SDK keeps in the Keychain. Device signals feed the integrity checks and the score, never the identity. | Not applicable. | The same visitor ID, because the Keychain record survives deleting the app. |
| Android (Kotlin SDK) | A random install ID the SDK keeps in a file excluded from backups. Device signals feed the integrity checks and the score, never the identity. | Not applicable. | A new visitor ID, because the record is removed with the app. |
React Native, Flutter and Lynx call the native SDKs, so they follow the iOS and Android rows. To pick one, see choosing an SDK.
What device fingerprinting cannot do
- Identify a person. A visitor ID identifies a device. Several people can share one device, and one person can use several.
- Follow someone across companies. Visitor IDs are scoped to your organization, and Fingerly does not link them across customers.
- Recognise every device. Some browsers and clients give away almost nothing, whether through hardened privacy settings or deliberately. They come back as
identifiable: false, and you should not count them as returning or unique. - Be a login. A visitor ID is a signal for your own rules, not a credential. Keep authenticating people the way you do now.
- Protect a decision made in the browser. A page or an app can be modified, so decide on your backend, from the stored event read with a secret key. See server-side verification.
Privacy and consent
Every Fingerly SDK takes a consent option and collects nothing until it is granted. Whether you need consent, and for what, depends on your lawful basis and where your visitors are. See privacy and consent for what is collected and what never is.
Try it
import { load } from '@fingerly/web-js'
// consent: 'granted' only once you have consent (or another lawful basis)
const fingerly = await load({ apiKey: 'fly_pk_development_…', consent: 'granted' })
const { visitorId, visitorConfidence, requestId } = await fingerly.identify({ tag: 'login' })
Send requestId to your backend, which reads the event with a secret key. The quick start walks through the whole round trip.