For companies
Fraud teams, security engineers, platform PMs. The teams that pay when fraud lands and the teams that pay when real customers churn.
Browser fingerprinting that catches fraud without false-positively challenging real customers. Calibrated risk scores, calibrated outcomes.
Browser fingerprinting is rarely just about one team. The same signal shapes outcomes for businesses, platforms, and the people who use them.
Fraud teams, security engineers, platform PMs. The teams that pay when fraud lands and the teams that pay when real customers churn.
Marketplaces, social networks, multi-sided platforms. Trust between users matters more than ever; sybil-resistance is a moat.
End-users. The under-discussed stakeholder. The people who get false-positively challenged, blocked, or asked to solve CAPTCHAs for being on Brave.
Six capabilities. Each one rooted in a real business outcome.
Four stages. The browser collects, the token carries the signal, the score is calibrated server-side, and your code makes the call.
Browser
The SDK collects 30+ browser signals client-side — canvas, WebGL, audio, fonts, hardware markers. Loaded async, never blocks DOMContentLoaded.
Token
The signals are wrapped in a signed token (ES256) and sent to your backend. The token can't be replayed; it carries the full fingerprint.
Score
Your server calls verify(). We return a 5-tier risk + confidence + flag trace. No DNS lookup; p99 under 12ms at the edge.
Decision
Your code reads the risk tier and decides. Block, challenge, observe, or allow — your policy, our receipt.
Four layers of signal, composed into one calibrated fingerprint. Each layer answers a different question — together, they're the difference between a verdict and a measurement.
Is the browser real?
Catch automated traffic, masked browsers, and synthetic visitors the moment they arrive — before they reach your signup, login, or checkout. Real customers pass through. Fake ones don't.
→ Detection categoriesIs the network safe?
Spot suspicious origins and high-risk infrastructure without punishing legitimate traffic. Remote workers, VPN users, and corporate networks stay welcome. Wholesale fraud sources get flagged.
→ Detection categoriesIs the device real?
Verify the real device behind the session — not just the software running on it. Genuine users on genuine devices breeze through. Bots running on shared, throwaway infrastructure surface immediately.
→ Detection categoriesIs the user real?
Tell a real person from a script by the rhythm of how they interact with the page. Humans hesitate, correct themselves, and explore. Automation moves with a tell-tale precision it can't hide.
→ Detection categoriesFour layers of signal, each answering a different question. Together they're the difference between a verdict and a measurement.
Six categories of threat. Each one tuned to catch automation, fraud, and abuse — without false-positively challenging real customers.
A browser request branches across six detection categories whose weighted signals combine into a single calibrated risk score.
Most fingerprinting services tell you what you want to hear: bot or human. Binary. Clean. Wrong. We tell you what the signal actually says, with confidence — and let your code decide.
// We don't tell you 'this is a bot.'
// We tell you risk: medium, confidence: 0.87.
// You decide.
Five tiers. Calibrated against population data — not binary, never silent.
Where signals become decisions. The operator console — search, compare, audit, decide.
Real numbers from real integrations. Bias toward false-negative; bias toward customer retention.
Sybil rings caught before review-bombing — by signal, not by IP.
New-device challenges instead of blocks. Real customers feel nothing.
Magic-link clicks verified by fingerprint match. Phishing kits stop here.
Six properties that hold up on inspection. No vendor magic — every one of them is auditable against the product surface.
EU data residency
GDPR-ready
Open SDK source
No PII collected
p99 verify <12ms
Calibrated, not magical
Operating constraints that show up everywhere — in the SDK, in the API, in the operator console.
You own the policy. We hand you the evidence.
Every threshold is documented and tunable. No black box.
A blocked customer never comes back. We bias against that.
No PII. No third-party calls. We can't sell what we never collected.
Real questions from real integrations. If yours isn't here, the docs probably cover it.
Tor exits get a default risk of `medium` from the IP signal (datacenter_asn + known-exit lists), but the fingerprint itself is still computed. If your application explicitly allows Tor — journalism, sensitive search, abuse-survivor flows — set `tor_policy: 'allow'` in the verify call to suppress the IP-based scoring while keeping every other signal active. The flag stays in the response either way; you just decide whether it counts toward the score.
All work. Each has distinctive fingerprints — Brave's farbling, LibreWolf and Tor Browser profiles are all known to our population data. Tracking-prevention features don't break verification; they just yield different (still consistent) fingerprints. We flag the protection level as an honest signal rather than silently penalizing the user.
Depends on the threshold you trigger on. With defaults (risk ≥ high → challenge), our internal benchmark against a ground-truth set of 4.2M real user sessions measures ~0.4% false positives. At risk = critical only, the FP rate drops to ~0.07%. Both numbers are continuously updated and visible in the operator dashboard, broken down by browser family and country so you can see where the misses come from.
Yes — the SDK collects in the browser and emits a signed token; verification happens server-side via our REST API. The token has the full fingerprint embedded and is verified cryptographically (ES256, `kid: nox-2026-01`), so `verify()` does no DNS lookups during a request. p99 verification latency is under 5ms because it's a signature check plus a cache lookup, not a re-collection.
We're a sub-processor under your DPA, with our own DPA available on request. We process fingerprints as 'personal data' because they could re-identify a returning visitor — full Article 28 controls apply. No third-country transfers; infrastructure is EU-resident (Cloudflare EU-only routing). Hard-delete on request via the backoffice. We can sign DPAs in 24h. Subprocessor list is at `/subprocessors`.
Five more questions live in the docs — on-prem, iframes, network behavior, threshold tuning, and Noxtica vs. CAPTCHA. → See all questions in docs
Stop fraud before it lands. Keep real customers moving. Get the calibration that fits your traffic — and a team that actually picks up the phone.
Everything you need to ship with confidence — and nothing you don't.