JA4 fingerprinting explained: how it improves on JA3, and what it actually identifies

JA3, the old way of fingerprinting a TLS client, broke when the browsers it watched started shuffling their own handshake. After Chrome began randomizing the order of its TLS extensions in 2023, JA3, which hashed those extensions in the order they arrived, produced a different value on almost every connection, so the fingerprint that was supposed to recognize a client recognized nothing. JA4, released the same year by FoxIO, is the answer: it sorts the values instead of trusting their order, stays human-readable, and covers more than just TLS. This guide explains what JA4 is, how it improves on JA3, and the part most write-ups skip, what it actually identifies and what it does not.

Key takeaways

• JA4 is a network fingerprint that identifies the software stack behind a connection, a browser, a script, or a tool, from the TLS Client Hello it sends, before any page code runs.
• It replaced JA3 because JA3 was order-sensitive: once browsers randomized their TLS extension order, JA3's hash changed on every connection. JA4 sorts the values, so reordering no longer breaks the match.
• A JA4 fingerprint is readable, not just a hash. Its parts spell out the TLS version, the cipher and extension makeup, and the application protocol, and JA4 is one of a family (JA4+) that also covers HTTP, TCP, and the server side.
• JA4 identifies a client type, not a person or a unique device. Everyone on the same browser and operating system can share one JA4, so it is a corroborating signal, never an identifier on its own.
• In fraud detection its value is the contradiction: a request that claims to be one browser but whose JA4 says it is a script or a tool is the tell, read at the network layer.

What is JA4 fingerprinting?

JA4 fingerprinting is a method of identifying the software behind a connection by reading the TLS Client Hello, the first, unencrypted message a client sends when it opens a secure connection, and condensing its characteristics into a short, standardized string. Because different software, a Chrome browser, a Python script, a Go HTTP library, builds that handshake differently, the resulting JA4 string is characteristic of the client type that produced it. It is the successor to JA3, created by FoxIO and published as an open specification, and it sits at the network and transport layer rather than in the browser. It is the JA4 piece of TLS fingerprinting more broadly.

The reason it reads the Client Hello is that this message is sent in the clear, before encryption begins, so a server can fingerprint the client without decrypting anything. What the fingerprint captures is configuration, the TLS version offered, the list of cipher suites, the extensions, and the application protocols, which together form a signature of the software, not the user.

How JA4 improves on JA3

JA3, introduced in 2017, hashed the Client Hello fields in the exact order the client sent them and reduced the result to a single opaque value. That worked until the order stopped being stable. When browsers began permuting their TLS extensions on purpose, a change Chrome rolled out in 2023, the same browser produced a different JA3 on every connection, and the fingerprint collapsed. JA4 fixes this by sorting the values before it builds the fingerprint, so a harmless reordering produces the same JA4. It also keeps the fingerprint readable instead of hashing everything into one blob, and it extends beyond TLS into a whole family of fingerprints. The differences at a glance:

	JA3	JA4
Introduced	2017	2023
Output	one opaque MD5 hash	a readable, multi-part string
Extension order	order-sensitive, breaks on reordering	sorts the values, survives reordering
Readability	none, just a hash	parts you can read (TLS version, cipher and extension counts, ALPN)
Scope	the TLS client only	a suite covering TLS, the server, HTTP, TCP, and more

The practical upshot is resilience. JA3 was easy to defeat by accident, every browser that randomized its handshake broke it, and easy to defeat on purpose. JA4 raises the bar on both, which is why detection tooling moved to it.

The JA4 string format

A JA4 fingerprint is written in readable parts, often shown as a_b_c, in a compact multi-part shape (the two trailing hashes are 12 characters each, while the readable first part varies). Each part answers a different question:

• Part a captures the protocol and transport, the TLS version, whether the connection is over TCP or QUIC, the presence of a server name, and the application protocol negotiated via ALPN (Application-Layer Protocol Negotiation), so t13 reads as TLS 1.3.
• Part b summarizes the cipher suites the client offered, as a count plus a sorted hash, so reordering the same ciphers does not change it.
• Part c does the same for the extensions and the signature algorithms.

A complete JA4 looks like t13d1516h2_8daaf6152771_02713d6af862: the t13d reads as TLS 1.3 over TCP with a server name present, the digits 1516 count the offered cipher suites (15) and extensions (16), h2 is the negotiated HTTP/2 preference, and the two trailing blocks are the sorted cipher and extension hashes. JA4 also ignores GREASE values, the deliberately random entries a browser adds to its handshake to keep the protocol extensible (defined in RFC 8701), so that padding never shifts the fingerprint.

Because the parts are separate and legible, an analyst can match on the whole string or on a single segment, and can read roughly what a client is from the fingerprint alone rather than looking it up in a table. Because a JA4 is readable and portable, common fingerprints are catalogued in open databases such as JA4DB and can be read directly in tools like Wireshark, so a value seen in your logs can be identified rather than reverse-engineered.

The JA4+ suite: more than TLS

JA4 is the TLS-client member of a larger family called JA4+, a set of fingerprints for different layers of a connection. The ones that come up most:

• JA4 fingerprints the TLS client from its Client Hello.
• JA4S fingerprints the server's response, the Server Hello.
• JA4H fingerprints the HTTP request, including the order of headers and the presence of things like an Accept-Language.
• JA4T fingerprints the TCP characteristics, such as window size, which can hint at the operating system or a proxy in the path.
• JA4X fingerprints an X.509 certificate, and JA4SSH covers SSH sessions.

Read together, the suite describes a connection from several angles at once, which is what makes a contradiction between layers, a TLS stack that does not match the HTTP behavior, so informative.

What JA4 can and cannot tell you

This is the part that matters most and is the easiest to get wrong. A JA4 fingerprint identifies a client's software stack, not a person and not a unique device. Everyone running the same browser version on the same operating system tends to produce the same JA4, so the fingerprint groups clients by type rather than singling anyone out. It is explicitly not designed to be unique, and there are real edge cases where it is not even stable for one client: Safari, for instance, can reuse a prior session through a TLS extension and present a different fingerprint on the next connection.

That is not a flaw to hide; it is the right way to use the signal. JA4 tells you what kind of client is connecting, with high confidence and almost no cost, and it tells you that server-side before a single line of page code runs. What it does not do is tell you who the visitor is or pin them to one machine. Treated as a corroborating signal rather than an identifier, it is genuinely useful. Treated as a unique ID, it produces false matches and misses.

JA4 in fraud detection

For threat hunters and web application firewalls, JA4 is mostly about grouping malicious traffic and rate-limiting clients that rotate IPs. For fraud and abuse detection the more useful read is narrower: the contradiction between what a client claims to be and what its JA4 says it is. A request can set a user-agent header that says Chrome on Windows, but the user-agent is just a string the client chooses, while the JA4 is produced by the actual TLS library underneath. When the header says one thing and the TLS stack says a scripting library or an automation framework, the mismatch is hard to fake and easy to read. A missing or unusual application protocol value, where a real browser would normally negotiate HTTP/2, points the same way.

That makes JA4 a strong corroborating signal for automated abuse and for anti-detect browser setups, which spoof the browser-side fingerprint but often miss the transport layer underneath. It is read alongside the rest of the session rather than acted on alone, because a shared JA4 is normal: the goal is to catch the session whose layers disagree, not to treat a common fingerprint as guilt.

How ShieldLabs uses the TLS signal

ShieldLabs reads the connection layer, including the TLS fingerprint, as one input among many, never as a standalone verdict. The TLS stack behind a request is one of the network signals it reads, cross-checked against the declared browser, the anonymity signals on the connection, and the rest of the session, so a client whose transport layer disagrees with what it claims to be raises the read rather than passing on a header alone.

ShieldLabs scores the session, the device, and the network, and names the signals behind a risk score from 0 to 100. You read that score and the named signals through the API and webhooks and decide, by your own rules, what a contradiction is worth. The TLS read is one corroborating layer in that picture, read alongside the broader TLS fingerprinting signal and the wider set of browser fingerprinting techniques.