JA3 and JA4 Fingerprints

JA3 is a fingerprint of a TLS client computed from the ClientHello, the first message a client sends when opening a connection. It concatenates the TLS version, the accepted cipher suites, the extension list, the elliptic curves and the curve point formats in the order they appear on the wire, then hashes the result to a single MD5 string. JA4 is its successor, published by FoxIO under a BSD 3-Clause licence and credited to John Althouse, who also worked on JA3. Rather than one opaque hash, JA4 produces three readable sections in an a_b_c form, for example t13d1516h2_8daaf6152771_e5627efa2ab1.

The FoxIO specification, read 2026-07-27, describes the first section as the protocol marker (q for QUIC, d for DTLS, t for TLS over TCP), a two-character TLS version, d or i for whether SNI is present, a two-digit cipher count, a two-digit extension count, and the first and last characters of the first ALPN value. The second section is a 12-character truncated SHA256 of the ciphers sorted in hex order. The third is the same over the sorted extensions followed by the signature algorithms, with SNI and ALPN excluded. Sorting is the point: JA3 preserved wire order, so browsers that shuffle their extensions on every connection produced a new JA3 each time and broke the fingerprint as an identifier. Sorting survives the shuffle, and the signature algorithms are folded in to restore the uniqueness that sorting would otherwise cost.

This is the highest-value detection signal a site has, because it arrives before a single byte of HTTP does. The fingerprint is a property of your TLS library, not your code, so Python requests via OpenSSL, Go net/http, curl, Node and Chrome each emit a distinct and well-catalogued value. No amount of header spoofing changes it. A scraper that sets a perfect Chrome User-Agent while handshaking as Python announces the mismatch in the handshake, and that mismatch is trivially detectable. Mitigation runs along a spectrum: impersonation libraries that replay a real browser's ClientHello byte for byte, running an actual browser so the handshake is genuine, or buying a vendor such as Scrapfly, ZenRows, Scrappey or ScrapeNinja that manages the TLS layer for you.

The diagnostic pattern is specific. If a block survives every proxy change, every header change and every IP type, and it fires on the very first request before any behavioural signal exists, suspect TLS. Confirm by sending the same request from a real browser on the same IP. If the browser gets through and your client does not, the handshake is the trip wire, and the choice is between an impersonating HTTP client, which is cheap and fast, and a full browser, which is expensive but leaves nothing to imitate.