JA3 vs. JA4 Fingerprints – Definition and Differences
Compare JA3 and JA4 TLS fingerprinting: what each hashes, why JA3 lost precision, what JA4 adds, and what both mean for client identification.
JA3 and JA4 are schemes for summarising a TLS client's handshake into a comparable identifier. Both describe how a client negotiates, which is characteristic of the library or browser producing it.
1. What JA3 Is
JA3 builds a string from selected fields of the client hello, then hashes it.
- Inputs: TLS version, cipher suites, extensions, elliptic curves, and curve formats.
- Output: an MD5 hash of the concatenated, comma-separated values.
- Property: two clients configured identically produce the same hash.
Its weakness is ordering sensitivity: a client that shuffles extension order produces a different hash on every connection, defeating matching entirely.
2. What JA4 Is
JA4 is the successor, designed to address JA3's practical problems.
- Structure: a readable, segmented identifier rather than one opaque hash.
- Sorting: values are sorted where order is not meaningful, so shuffling no longer changes the result.
- Coverage: part of a family covering TLS client and server, HTTP, and other protocols.
- Readability: segments encode protocol, cipher count, extension count, and ALPN, so the identifier carries information before any lookup.
3. Key Differences
| Aspect | JA3 | JA4 |
|---|---|---|
| Output | Single MD5 hash | Segmented, partly human-readable |
| Order sensitivity | High — shuffling breaks matching | Reduced by sorting |
| Information without a database | None | Protocol and counts visible directly |
| Scope | TLS client hello | A family across several protocols |
| Ecosystem | Long-established, widely deployed | Newer, increasingly adopted |
4. Why Ordering Mattered So Much
Once browsers began randomising extension order, a single browser produced many JA3 hashes. Blocklists and allow-lists keyed on JA3 became unreliable, and the scheme's usefulness degraded through no change in the underlying handshake.
JA4's sorting means the same client yields a stable identifier despite randomisation, which is the main reason for adoption.
5. What Both Actually Measure
Neither identifies a person or a machine. They characterise the TLS library and its configuration — which is why they group clients into families rather than individuals.
That grouping is the value: a request declaring a mainstream browser in its user agent while presenting a scripting library's TLS fingerprint is internally contradictory, and the contradiction is measurable without inspecting content.
6. Practical Implications
- For site operators: a signal among many, useful for grouping and correlating rather than deciding alone. Many legitimate clients share a fingerprint.
- For client authors: consistency across layers matters more than any single value. A handshake that matches the user agent it claims is coherent; one that does not stands out.
- For everyone: these are fingerprints of software, so they change when that software changes, and any static list of "known good" values ages quickly.
7. Limits
Shared fingerprints across many users mean false positives are inherent, so blocking on fingerprint alone is a blunt instrument. Fingerprints also shift with library and browser updates, requiring continuous maintenance of any list built on them.
8. Summary
JA3 hashes an ordered summary of the TLS client hello; JA4 replaces it with a sorted, segmented, partly readable identifier that survives extension randomisation and extends across protocols.
Both describe client software rather than identity, and their practical significance is the same: what a connection reveals before any header is read, and whether the layers of a client's presentation agree with each other.