Your TLS handshake identifies your client before a single byte of HTTP is sent. The fingerprint that does it changed — from JA3 to JA4 — and if your tooling is still playing the old game, you're already flagged.
JA3 hashed an order-sensitive list of TLS Client Hello fields. When Chrome started randomizing TLS extension order, every Chrome request produced a different JA3 — breaking it for the world's most common browser. JA4/JA4+ replaced it: it sorts order-variable fields before hashing, is human-readable, and is modular across TLS, HTTP and TCP. It's stable and much harder to spoof — and it's what blocks you in 2026 if your fingerprint doesn't match your claimed browser. The fix is to look like a real browser on a real mobile IP.
JA3 worked by concatenating fields from the TLS Client Hello — version, cipher suites, extensions, elliptic curves, and point formats — in the order they appeared, then hashing the string. For years that order was stable per browser, so the hash was a reliable signature.
Then Chrome started randomizing the order of TLS extensions on every connection as an anti-ossification measure. Because JA3 was order-sensitive, the same Chrome now produced a constantly changing JA3 — making the fingerprint useless for the single most important browser to identify. Anti-bot vendors couldn't rely on it anymore.
| JA3 | JA4 / JA4+ | |
|---|---|---|
| Extension order | Order-sensitive (breaks on randomization) | Sorts order-variable fields → stable |
| Readability | Opaque MD5 hash | Human-readable, structured |
| Scope | TLS only | Modular: TLS, HTTP, TCP, latency (JA4+ suite) |
| Post-quantum aware | No | Reflects PQ key-shares in the handshake |
| Spoof difficulty | Moderate | High — must match a real, current client |
JA4 is one layer of the broader 2026 fingerprinting stack, and it now carries post-quantum key-share information too — so an outdated TLS profile fails twice over.
Both fingerprint the TLS Client Hello, but JA3 hashed a fixed, order-sensitive list of fields. When Chrome began randomizing the order of TLS extensions, every Chrome request produced a different JA3 — making it useless for identifying Chrome. JA4 fixes this by sorting order-variable fields before hashing and by being human-readable and modular (JA4+ covers TLS, HTTP, TCP and more). The result is a stable, harder-to-spoof fingerprint.
Rarely as a primary signal. Chrome’s extension-order randomization broke JA3’s usefulness for the most common browser, so anti-bot vendors moved to JA4/JA4+. You may still see JA3 logged for legacy reasons, but blocking decisions in 2026 lean on JA4 and related signals.
The most reliable way is to actually be a real, current browser engine rather than a raw HTTP client — then your JA4 is correct by construction, including post-quantum key-shares. If you use a TLS-impersonation library, keep its profiles current. Either way, pair the matching fingerprint with a real mobile IP so the network layer agrees; a perfect JA4 on a datacenter IP is still suspicious.
A real browser's JA4 on a real 4G/5G mobile IP is the consistent combination. 17+ countries, $4/GB, free endpoints and rotation.