Fingerprint competitors and alternatives

The alternatives, briefly

Kaidn compared with Fingerprint

Recognising a returning browser or device very accurately, with extra signals like VPN, bot and tamper detection alongside.

Fingerprint does one thing extremely well. It tells you this browser is the same browser you saw before, accurately, even when somebody is actively trying to stop it. That is a specialist tool, and specialists are usually better at the thing they specialise in.

We are not trying to beat them at identifying devices. We use it as an input.

We return different things#

Fingerprint returns a visitor ID plus Smart Signals: VPN, bot, browser tamper, proxy, jailbroken device, iOS simulator. You take those and decide what they mean.

We return a verdict. The device signals go in next to the IP, the email, the phone, how fast things are repeating, and the cross-operator graph. What comes out is allow, review or block with the checks that fired and what each one counted for.

Want an identifier? They are the better tool. Want a decision? That is us. Plenty of teams run both, and that is a sensible architecture, not a hedge.

We both return a confidence number, and you should read ours#

Fingerprint returns confidenceScore on the visitor ID, which is 1 - falsePositiveProbability.

That number exists because everyone serious in this market knows the same thing. A raw browser fingerprint is a hash of settings, and identical settings produce identical hashes. A default iPhone really is identical to another default iPhone.

We return the same kind of number under a different name. Every scored event carries a resolved_id, the method that produced it, and a collision_risk, which is the measured chance the identity covers more than one real person.

Those numbers are measured on real traffic, not modelled. On iOS Safari, 2.30 people per raw fingerprint falls to 1.27 once the network is taken into account. Across all traffic, 1.53 falls to 1.14.

We publish the ones that do not flatter us too. iOS Safari still sits at 0.21 even after that improvement, which is why an iOS Safari identity is never allowed into the cross-operator graph.

Here is the honest version of this comparison. Fingerprint is better at level 2, because a decade of work on probabilistic identification is exactly what level 2 is. At level 1 the two products do the same thing, because a signed cookie replayed by your own server is not a research problem. The question is which unit of output you want around it. Full mechanics in the device identity docs.

What the plans buy#

Their free tier is 1,000 API calls a month, with Pro Plus at $99 a month for 20,000 calls and $4 per additional 1,000. Ours is 10,000 events free and $99 for 250,000.

It is not like for like. A Fingerprint API call is one identification. A Kaidn event is a scoring decision across every signal we hold.

But the shape matters. Their cost above the bundle adds up at volume, and collection on our side is free, because we bill the decision rather than the fingerprint.

Read the confidence, not just the id#

Both products hand back an identity and a number saying how much to trust it. The part teams skip is actually branching on that number.

A device-reuse verdict built on a level 3 identity does not deserve the same treatment as one built on level 1:

{
  "verdict": "review",
  "reasons": ["device_reuse"],
  "device": {
    "id": "8f1c2ae9d4b7c3e05a1f6b28d9074e3c",
    "resolved_id": "d2c1f0a7b93e4d5681ca07f4e2b91d38",
    "resolution": "probabilistic",
    "resolution_rung": 2,
    "collision_risk": 0.21,
    "account_count": 3,
    "account_count_same_network": 1
  }
}

const r = await kaidn.score({ event: "cashout", user_id, ip, email, device_id });

// A device link on a high-collision identity (iOS Safari sits at 0.21 even after
// the network is folded in) is a hint, not a finding. Corroborate it before acting.
const deviceOnly = r.reasons.length === 1 && r.reasons[0] === "device_reuse";
if (deviceOnly && (r.device?.collision_risk ?? 0) > 0.15) return allowWithFlag(r.event_id);

if (r.verdict === "block") return deny(r.reason_text);
if (r.verdict === "review") return hold(r.event_id);

Read account_count_same_network next to it. Three accounts on one device across three different networks is a much weaker claim than three on the same network.

This is the same discipline confidenceScore exists for on their side. The mistake it prevents is real and expensive: banning a crowd of ordinary iPhone users because their fingerprints agree with each other.

Running both#

Plenty of teams should, and the wiring is dull. Their visitor id becomes the device_id on the scored event, so you keep their accuracy and get a verdict around it:

import { load } from "@fingerprintjs/fingerprintjs-pro";

const fp = await (await load({ apiKey: PUBLIC_KEY })).get();

// hand their visitorId straight to the scorer as the device identity
const { verdict, reasons } = await kaidn.score({
  event: "signup",
  user_id: user.id,
  ip,
  email: user.email,
  device_id: fp.visitorId,
});

Nothing in the scoring engine requires the id to have come from @kaidn/fp. If you already pay for better identification, use it.

Where we would send you elsewhere#

Their accuracy has years of focused engineering behind it. If a returning-visitor ID is genuinely what you are buying, buy theirs. If you need native mobile, buy theirs. And if budget is the constraint, the open-source FingerprintJS is free and may well be enough.

The problem we both share#

We ran both engines side by side on the same page loads and published the numbers, including the ones that do not flatter us. Two findings worth reading before you choose either product.

Their script did not run at all on 21 of 24 privacy and anti-detect browser sessions, because EasyPrivacy and EasyList carry rules for their domains. And on a clean anti-detect profile running the same operating system it claimed, neither engine caught the session.

Full data, method and limitations: what a fingerprinting vendor sees when the browser blocks its agent.