A public, free lookup service for TLS client fingerprints.
Paste a JA3 or JA4 to see what software opened a connection — and, across the domains it reaches, how it behaves. Or look up a domain to see whether it has been reached through a residential proxy network, and by which clients.
- fingerprints
- —
- observations
- —
- domains
- —
How it works
The corpus is built from inside a residential proxy network. We join it as a swarm of peers — decoys that do nothing but listen.
- 1Every session routed through a decoy drags its TLS ClientHello and the domain it is reaching for.
- 2We record the fingerprint and the server name — never the peer’s IP. Just
(fingerprint, SNI). - 3Folded together, millions of these become a reputation: what the software is, and how it behaves across everything it touches.
ALPN offers
ALPN is the one thing you can read off a single handshake. A browser offers h2 then http/1.1, in that order; a library offers http/1.1 or nothing at all. Here is how the corpus splits — by connections, and by the distinct fingerprints behind them.
The amber slice is h2, http/1.1 — the browser offer. It carries most of the connections but a smaller share of the fingerprints: a handful of library offers fragment into many distinct stacks.
Who is behind each offer
The amber length is the share we can name; the neutral tail is still anonymous. Browsers cluster in h2, http/1.1; the HTTP-library stacks — Node, Python — show up under http/1.1 and (none).
The graph
Every fingerprint that reached www.google.com, sized by how much traffic it carried. Real browsers cluster; the odd library or bot sits off on its own. This is one slice — explore the whole graph →
FAQ
What is this for?
A reputation lookup for TLS client fingerprints. The corpus is gathered inside a residential proxy network, so it leans toward the traffic worth scrutinising: a fingerprint seen here is software that routes through anonymising proxies, across every domain it reaches. Compute the JA4 of an incoming ClientHello, look it up, and decide how far to trust the connection.
Why does being seen on a proxy network mean anything?
Most people connect directly. Traffic that deliberately exits through a residential-proxy pool is disproportionately automation — scrapers, checkout and sneaker bots, credential stuffing, fraud tooling. A stack that reaches dozens of unrelated login endpoints this way is not a person having a day. Presence is not proof of abuse, but it is exactly the population worth a second look.
Then why are browsers not flagged too?
A real browser is the one client with an innocent reason to be proxied — a privacy-minded person on a VPN — and the one client you can challenge. Chrome and Firefox run JavaScript, so a JS or CAPTCHA challenge tells a genuine browser from a headless one wearing its fingerprint. curl, Go's net/http, Python and most bots cannot pass that, and have no honest reason to be in a proxy pool at volume. Rule of thumb: browser-shaped, defer to a JS challenge; not browser-shaped and widely seen on proxies, treat as bad.
Is “bad reputation” a verdict?
No — it is one signal. The site never says a connection is fraud; it says a fingerprint has this shape and this history. Use it alongside your own signals to decide whether to allow, rate-limit, challenge or block.
Does this track people?
No. A TLS fingerprint identifies software, not a person: everyone on the same Chrome build shares one. Nothing here records who opened a connection.
What do you actually store?
Aggregates only — (fingerprint, domain, counter). We record that some client stack reached some server name, and how often. Never an IP, never the proxy peer's identity, never a per-person browsing history. A row is a statistic, not a log.
Can I see my own fingerprint?
Yes — the fingerprint checker reads it live from the probe: your JA3 and JA4, and how the corpus sees them.