JA4 fingerprint lookup

What is JA4?

JA4 is a TLS client fingerprint introduced by FoxIO in 2023 as part of the JA4+ family. It identifies a client by the structure of the TLS ClientHello — its cipher suites, extensions, ALPN values, and supported groups — rather than by IP or User-Agent. Two clients running the same library on the same platform share a JA4; different libraries produce different fingerprints even when impersonating one another at the HTTP layer.

JA4 replaces the older JA3 fingerprint, which suffered from instability once TLS 1.3 GREASE values made cipher and extension lists vary between handshakes from the same client. JA4 normalizes these out before hashing.

How it works

A JA4 fingerprint has three sections separated by underscores — for example, q13d0309h2_55b375c5d22e_06cda9e0adb1. The first segment is a readable prefix encoding the protocol (t for TCP, q for QUIC), the negotiated TLS version, whether SNI was present, the ALPN value, and the counts of ciphers and extensions. The second segment is a 12-hex-character truncated SHA-256 of the sorted cipher list. The third is a hash of the sorted extension list, with SNI and ALPN omitted from that list because their values are content-dependent.

Because GREASE values (RFC 8701, used to keep middleboxes from ossifying on specific TLS extensions) are filtered before hashing, JA4 is stable across the random extension picks a single client makes between handshakes.

When to use this tool

• Bot detection — comparing a connection's JA4 against known libraries (curl, Python requests, Go net/http) versus genuine browsers.
• Identifying malware families that ship with their own TLS stack and therefore produce a distinctive fingerprint.
• Investigating CDN or WAF logs where the JA4 column is more discriminating than the User-Agent.
• Building allow/deny lists for legitimate automation (your own monitoring, partner integrations).
• Reverse-engineering an unfamiliar client to understand which library generated the traffic.

Common pitfalls

• JA4s drift across library versions. A client's JA4 in OpenSSL 3.0 and OpenSSL 3.2 are not guaranteed to match — fingerprints are version-tagged in any serious database.
• JA4 and JA3 are not interchangeable. A signature library that quotes one will not necessarily quote the other; mapping between them is lossy.
• JA4 fingerprints the client (ClientHello). The server-side counterpart is JA4S, which fingerprints the ServerHello. Looking up a server fingerprint here will not find a match.
• A JA4 alone is not authentication. An attacker can clone any TLS stack and produce the matching fingerprint — JA4 narrows the field, it does not prove identity.
• Many libraries share a fingerprint. curl linked against the same OpenSSL build as another tool may produce an identical JA4.

Frequently asked

Where does the fingerprint database come from?

From ja4db.com, FoxIO's public corpus of known fingerprints. We mirror it locally and refresh every six hours so lookups stay fast and stable even when the upstream is unavailable.

How fresh is the data?

The local snapshot is at most six hours stale. New fingerprints contributed to ja4db.com appear here on the next refresh cycle.

Can I look up a server's JA4S fingerprint?

Not in this tool. JA4S is computed from the server's ServerHello and is a separate fingerprint family. This tool indexes JA4 (client) only.

Why does my JA4 not match anything in the database?

Either the database has not seen that exact stack version yet, or the client is custom (modified TLS settings, novel library). A miss is useful information — it suggests the client is not a mainstream browser or library.