A browser fingerprint API built for server-side decisions

Collect browser fingerprint signals in the page, protect them with a short-lived token and exchange that token on your backend. The result is designed for developers who want the raw evidence, stable fields and freedom to write their own policy.

Create a free project Explore the API

Start with the free plan. No card required.

More useful than a hash in the browser

A client-side fingerprint alone is easy to copy into a request and difficult to interpret. IPCheckHQ binds browser observations to the network request that collected them, then returns the readable result only to your authenticated backend. That gives you a cleaner boundary between untrusted client code and the decision that creates an account or grants a benefit.

The response includes a project-scoped identifier, the open-source visitor identifier and component hashes for canvas, WebGL, audio and other signals. Confidence and randomized-signal fields help you distinguish stable observations from values a privacy browser is deliberately changing.

What you can build with it

Frontend collection, backend trust

The browser receives a single-use token. Your server exchanges it for the actual result using a secret key.

Inspect the components

Use the combined identifier for common cases and retain component-level evidence when you need to investigate changes.

A documented contract

Versioned endpoints, explicit nulls and stable error codes make the API predictable in signup and authentication flows.

A short path from browser to backend

1
Load verify.js
Use the public project key and restrict it to the origins that are allowed to collect tokens.
2
Run on submission
Collect immediately before the protected action and attach your own reference so the response can be joined to the attempt.
3
Exchange before approval
Validate the token on your server, store the fields you need, and choose the correct response for your product.

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

Fingerprint confidence is an estimate of stability, not the probability that a visitor is malicious.
Private browsing does not guarantee a new fingerprint, and clearing cookies does not guarantee the old one disappears.
A determined attacker can alter browser signals. Treat inconsistencies as evidence to examine rather than automatic grounds for rejection.

Privacy is part of the implementation

Browser fingerprinting can be regulated differently from ordinary functional storage. Explain the purpose clearly, minimize the fields you retain, avoid passive collection across unrelated pages, and obtain consent where your use requires it. IPCheckHQ keeps identifiers scoped to your project.

Read the IPCheckHQ privacy approach

Practical questions

Does the browser see the full verification result?: No. It receives an encrypted, single-use token. Your authenticated backend exchanges that token for the result.
Do I need to use every returned signal?: No. Start with the smallest set that supports a documented rule and add more only when you can explain why they improve the decision.

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