What is TLS fingerprinting (JA3 and JA4)?

02Why JA4 replaced JA3

JA3 hashes extensions in the order the client sends them, and that order stopped being stable. In November 2022 the Chromium team announced that Chrome would randomise the order of its Client Hello extensions, explaining that a fixed order encourages servers to fingerprint Chrome and then assume specific behaviour. Once that rolled out, the same browser produced a different JA3 hash on almost every connection.

That is a different mechanism from GREASE, which is often blamed for the same effect. GREASE, standardised in RFC 8701, has clients advertise reserved dummy values so that servers stay tolerant of values they do not recognise. JA3 and JA4 both ignore those values.

JA4, published by FoxIO, sorts cipher suites and extensions before hashing, leaves the SNI and ALPN extensions out of the extension hash, and puts a readable summary in front of two truncated SHA-256 hashes. The protocol, TLS version and counts are visible without a lookup table, which makes it far easier to reason about and to debug. The original JA3 repository was archived in May 2025.

03Reading a JA4 fingerprint

The JA4 specification uses the fingerprint below as its worked example. The first part is plain text; the other two are hashes that only match exactly. Signature algorithms are added to the third hash in their original order, while ciphers and extensions are sorted.

t13d1516h2_8daaf6152771_e5627efa2ab1
└───a────┘ └─────b────┘ └─────c────┘

a = readable prefix   b = cipher hash   c = extension hash

04What it actually catches

The classic case is a script claiming to be a browser. A Python request sending a Chrome user-agent negotiates like Python, because it is Python, and its fingerprint matches no browser build. The contradiction between claimed identity and observed handshake is the signal.

It also groups activity. If one fingerprint is shared by thousands of addresses that all appeared in the last minute and all request the same login endpoint, that is probably one tool being run at scale, which is the usual shape of credential stuffing and of bulk web scraping.

The idea extends past TLS. Akamai researchers showed in 2017 that HTTP/2 clients can be passively fingerprinted from differences in how they implement the protocol, and JA4H applies the approach to the HTTP request itself. A client whose HTTP behaviour contradicts its TLS handshake is telling two different stories.

05The limits, and the trap

A fingerprint is shared, not unique. Every Chrome user on the same version and platform produces the same value, which is good for privacy and a hard constraint for detection: a fingerprint identifies a class of software, never an individual.

That leads to a common and costly mistake. It is tempting to treat many requests sharing one fingerprint as evidence of a botnet, but legitimate browser traffic is extremely homogeneous, because most visitors run one of a handful of current browser builds. Real traffic can easily be more uniform than the attack you are trying to catch, which is why sound bot management treats a fingerprint as context rather than a verdict.

06Can it be evaded?

Yes, and increasingly easily. Libraries such as uTLS exist specifically to parrot the Client Hello of popular browsers, and a headless browser needs no impersonation at all because it genuinely is a browser.

This does not make fingerprinting useless. It raises the cost of an attack, which is the actual goal, and a forged handshake still has to agree with everything else the client sends. It does mean the fingerprint must be one input among many. Sound systems combine it with the other ways websites tell bots from humans, such as header coherence, behaviour, network reputation and the outcome of a proof-of-work challenge, and require several to agree before acting.

07How to look at a fingerprint yourself

The quickest way to understand the method is to look at real handshakes. Capture a few Client Hellos with tcpdump and open the file in Wireshark: version 3.6 and later show a JA3 field for each Client Hello, and version 4.2 and later add JA4.

The filter below matches TLS handshake records (content type 22) whose first message is a Client Hello (type 1) on port 443. It assumes the record starts at the beginning of the TCP payload, which holds for the first data segment of a connection, and it only matches IPv4, because tcpdump cannot index into a TCP header carried over IPv6.

It helps to place this in the OSI model: the handshake rides on TCP, and everything it reveals is known before HTTP begins. HTTP/3 is different, because QUIC carries its Client Hello inside protected Initial packets over UDP, so this TCP filter will not see it, although Wireshark can still decode those packets.

# TLS handshake record (0x16) carrying a Client Hello (0x01) on port 443, IPv4 only
tcpdump -ni eth0 -c 20 -w hello.pcap \
  'tcp dst port 443
   and tcp[((tcp[12:1] & 0xf0) >> 2)] = 0x16
   and tcp[((tcp[12:1] & 0xf0) >> 2) + 5] = 0x01'

# open hello.pcap in Wireshark and filter on: tls.handshake.type == 1