FP FINGERPRINT

Concepts

Fingerprint.dev returns identity evidence, not a cookie. The core model is a visitor, a set of fingerprint signals, and a confidence score.

Visitor ID

visitor_id is the stable ID returned by a successful identify request. Store it in your application if you need to join events, flag suspicious behavior, or attach device evidence to an account workflow.

Do not treat a visitor ID as authentication. It is useful evidence, not proof that a human owns an account.

Confidence

confidence is a number from 0.0 to 1.0. Higher values mean the service found stronger evidence that the request belongs to a known visitor.

kind is "new" when the service created a visitor record for this request and "match" when it matched an existing visitor.

Common patterns:

  • Use high-confidence matches for silent risk scoring.
  • Require extra review or step-up checks for low-confidence sensitive actions.
  • Store the confidence beside your own event so later investigations can see why a decision was made.

Connection fingerprints

The hosted API computes connection-level hashes from the request where available:

  • ja4: TLS ClientHello fingerprint.
  • ja4t: TCP fingerprint.
  • ja4h: HTTP header fingerprint.
  • ja4x: client certificate fingerprint when a client certificate is presented.

These are hashes and summaries, not raw request bodies.

Browser signals

The JavaScript SDK can add browser-side evidence such as canvas, WebGL, audio, screen, fonts, and navigator-derived values.

The SDK hashes present values locally. If a signal cannot be collected, it remains null. Missing evidence is better than a stable fake value.

The matcher keeps per-axis browser hashes internally. Stable rendering signals carry more identity weight; volatile window or navigator-derived signals are retained as evidence but should not block a same-browser match by themselves.

Allowed origins

API keys can be restricted to exact browser origins. The origin allowlist protects public browser keys from use on unapproved sites.

Use an empty origin list for server-to-server keys. Use explicit origins for browser keys.

Events

Each successful identify request records an event. Events let you inspect request history for a visitor, review confidence over time, and confirm which signals were present.