JA4 Fingerprint Directory

JA3 and JA4, and why the difference matters here

A TLS fingerprint identifies a client by how it is built, not by anything it claims. The cipher suites it offers, the extensions it sends, the order they appear in — all of that is decided by the TLS library and its configuration, and none of it is affected by changing a User-Agent string.

JA3 hashes the whole ClientHello into one MD5. It works, but it throws away every bit of structure: two fingerprints that differ by one cipher look no more related than two from unrelated software.

JA4 keeps the structure. The first component is plain text you can read without a lookup table — transport, TLS version, whether a server name was sent, how many ciphers and extensions, which ALPN. The second and third hash the ciphers and the extensions separately. That separation is what lets this directory group a scanner's twelve fingerprints into one family, because they share an extension hash while their cipher hashes differ.

How this database is used

It is not a reference list. The proxy loads it at startup and consults it on every TLS handshake, matching JA4 first and falling back to JA3, and the classification it returns feeds blocking, rate limiting and per-route allowlists. Two further checks run alongside it:

Replay detection flags one fingerprint appearing from many addresses inside a window — a single client build spread across a botnet. Drift detection flags a fingerprint whose cipher or extension composition changes while its hash stays put, which is the signature of something trying to wear another client's identity.

Directory generated 2026-09-22T09:30:02+00:00. Want to know your own? The Handshake Mirror reports it, along with the rest of your connection.