Recognize a returning browser without relying on its IP

IP addresses rotate, mobile networks are shared and VPN exits are noisy. A device fingerprint API gives your application another way to recognize repeat activity while preserving the difference between a likely browser match and a verified human identity.

Create a free project Explore the API

Start with the free plan. No card required.

Continuity across changing networks

A customer may move from home Wi-Fi to mobile data without becoming a different person. Conversely, hundreds of unrelated people can appear behind the same office gateway or carrier address. Rules built only on IP addresses create both gaps and false positives.

IPCheckHQ derives a stable, project-specific device ID from browser observations and returns the component hashes that support it. Your backend can check whether that device has appeared in its own history, then use the current network and account context to decide whether the repeat is normal, noteworthy or risky.

What you can build with it

Stable inside your project

The same observed browser receives a consistent identifier for your project without exposing a universal cross-customer ID.

Explainable matching data

Canvas, WebGL, audio and composite hashes let an investigator understand which parts remained stable and which changed.

Designed for your database

Attach an internal reference at collection time and store only the result fields needed for your retention and risk model.

A short path from browser to backend

1
Observe
Collect browser signals at a signup, trial or other protected action.
2
Resolve
Exchange the token on the server and read the project-scoped device ID plus supporting evidence.
3
Compare
Query your own event history or the eligible identity lookup endpoint, then combine the match with current account context.

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

The identifier describes an observed browser environment, not a motherboard, phone serial number or legal identity.
Browser upgrades and anti-fingerprinting protections can split one physical device into multiple observed identities.
Identically configured managed devices can collide. Do not assume a match proves two accounts have the same owner.

Privacy is part of the implementation

Use device recognition for a specific, disclosed purpose and set a retention period that matches it. Keep the identifier within your security or abuse workflow, provide appropriate user information, and avoid treating it as a hidden advertising identifier.

Read the IPCheckHQ privacy approach

Practical questions

Will the ID survive a changed IP address?: Often, because the device ID is derived from browser signals rather than the IP. Browser or privacy changes can still produce a different ID.
Is this a hardware fingerprint?: No. Web browsers do not expose a reliable hardware serial number. The API describes the browser environment it can observe.

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