Browser fingerprint matching with the uncertainty left in

A useful matching system should tell you what stayed the same, what changed and how much confidence to place in the comparison. IPCheckHQ exposes exact identifiers and component evidence so your team can test matching rules against its own traffic.

Create a free project Explore the API

Start with the free plan. No card required.

Matching is not the same as equality

Exact identifiers are fast and valuable, but real browsers evolve. A version update can alter one component while the rest of the environment stays stable. At the same time, broad signals such as screen size or timezone are shared by many people and should never carry a match by themselves.

The practical approach is layered: start with an exact project-scoped device ID, inspect stable component hashes when an investigation needs more context, and introduce similarity thresholds only after replaying them against known examples from your own product. IPCheckHQ does not turn a partial match into an automatic fraud verdict.

What you can build with it

Exact matches first

Use the stable device ID for the common path and keep the rule easy to audit.

Component-level evidence

Compare the signals that matter instead of treating every browser property as equally distinctive or stable.

Thresholds you can validate

Evaluate similarity against your own false-positive cost, user population and browser mix before enforcement.

A short path from browser to backend

1
Record known events
Store the project-scoped ID and the minimum supporting fields for legitimate and abusive examples.
2
Replay candidate rules
Measure exact and partial matching behavior against those examples before changing the customer experience.
3
Roll out gradually
Observe first, add review or step-up checks next, and reserve hard actions for combinations with strong independent evidence.

Representative exchange response

POST /api/verify/v1/exchange

{
  "device": {
    "id": "dev_7da…",
    "visitor_id": "f8c…",
    "confidence": 0.97,
    "canvas_hash": "sha256:…",
    "webgl_hash": "sha256:…"
  },
  "network": {
    "asn": 13335,
    "network_type": "residential",
    "vpn": false,
    "hosting": false
  },
  "consistency": {
    "timezone_matches_ip": true
  }
}

Limitations worth designing for

Similarity weights and thresholds are specific to a dataset; copying a value from another product is not responsible validation.
Common signals can make unrelated browsers look similar, while privacy defenses can make one browser look different between visits.
Current API fields provide evidence for matching. Your application remains responsible for the rule, outcome and appeal path.

Privacy is part of the implementation

Matching increases the importance of purpose limitation and retention. Store comparisons only as long as the abuse or security use case requires, restrict who can query them, and give legitimate users a recovery path when an automated rule adds friction.

Read the IPCheckHQ privacy approach

Practical questions

What is an exact fingerprint match?: It means the project-scoped device identifier was reproduced. It is strong evidence of the same observed browser environment, not proof of the same person.
Should I block on a partial match?: Usually not. Partial matches are better used to prioritize review or request another independent check.

Test the workflow in your own application

Create a project, allow your development origin and complete the first token exchange before choosing an enforcement rule.

Create a free project