What is JA4?
JA4 is the TLS client fingerprint in the JA4+ family published by FoxIO, designed to replace JA3. Rather than one opaque MD5, it produces a partly readable string: a ten-character prefix describing transport, TLS version, SNI, cipher and extension counts and ALPN, followed by two truncated SHA-256 digests of the sorted cipher and extension lists.
The prefix is the part you can read without tooling. It records the transport (t for TCP, q for QUIC), the highest TLS version the client offers as two digits, whether SNI carried a domain or a bare IP, a two-digit cipher count, a two-digit extension count, and the first and last characters of the first ALPN value. A prefix like t13d1516h2 is TLS 1.3 over TCP with a domain in SNI, 15 ciphers, 16 extensions and h2 negotiated first. Two truncated SHA-256 digests follow.
Sorting is the substantive change from JA3. JA4 orders the cipher and extension lists numerically before hashing them, so a browser that shuffles its extension order per connection collapses back to one stable value. SNI and ALPN are excluded from the extension digest because they change with every destination, while signature algorithms are appended in their original order. GREASE code points are ignored. What comes out is a fingerprint that holds still for a given browser build across sites.
Readability lets an analyst pivot without a lookup table. You can match on the prefix alone, picking out every client speaking TLS 1.2 with no SNI, or compare counts when a client sends a different number of ciphers than the browser it claims to be. JA4 sits in a family that also covers server hellos, HTTP headers, X.509 certificates and SSH sessions. Licensing is not uniform across that family, so check the terms for the specific variant before shipping it in a product.
For automation work, JA4 raises the cost of a partial imitation. Passing as a browser means reproducing its exact cipher and extension sets along with its ALPN, since the counts appear in plain text and a mismatch needs no hash comparison at all. Detection stacks normally read JA4 next to the HTTP/2 SETTINGS frame, header order and the exit IP's ASN, then score the combination. Libraries that replay a captured browser handshake, uTLS among them, are the practical route.
Where you meet it
You meet JA4 in newer bot-management logs and WAF rules, usually printed beside the older JA3 hash. It comes up when an allowlist built on JA3 stopped working after a browser release, or when a vendor dashboard groups your traffic under a fingerprint you did not expect. Read the ten-character prefix before anything else, since the version, SNI, the two counts and ALPN normally explain the mismatch without touching the digests.
Common questions
What is the difference between JA3 and JA4?
JA3 hashes five ClientHello fields in their original order into one MD5. JA4 sorts the cipher and extension lists before hashing, which survives browsers that randomise extension order, and it keeps a readable prefix carrying transport, TLS version, SNI, counts and ALPN so you can filter without a hash lookup table.
Does JA4 identify an individual user?
No. It identifies a TLS stack and its configuration, so every user of the same browser build on the same platform shares a value. Detection systems combine it with header order, HTTP/2 settings, device signals and the source IP before they treat anything as a single identity.
Can JA4 be spoofed?
Yes, if you control the TLS stack. Tools that replay a real browser's ClientHello, such as uTLS or curl-impersonate, reproduce the cipher and extension sets a target browser sends. Half measures fail quickly, because the cipher and extension counts sit in the readable prefix where any mismatch is obvious.
Related terms
Real 4G/5G mobile and residential IPs
PROXIES.SX runs carrier IPs in 100+ countries with HTTP and SOCKS5 on every endpoint. $4/GB down to $2.40/GB at volume, free endpoints and rotation, and your GB never expire.