JA3 Fingerprint vs JA4: TLS Client Fingerprinting Guide
What a JA3 fingerprint is, how JA4 differs, why Chrome's extension-order randomization broke JA3 stability, and how defenders use TLS fingerprints in triage.
TL;DR. A TLS client fingerprint summarises how a client builds its ClientHello: which versions, cipher suites, extensions and parameters it offers. JA3 (2017) hashes five of those fields, in the order sent, with MD5. When Chromium began randomizing extension order in early 2023, the same browser started producing a different JA3 on almost every connection. JA4 (2023, FoxIO) sorts ciphers and extensions before hashing and keeps a readable prefix, so it stays stable and is easier to reason about. Defenders use both to cluster clients, spot tools that do not match the rest of an environment and pivot in threat intelligence. A fingerprint identifies a TLS stack, not a piece of malware.
Why fingerprint TLS at all
In a capture, TLS payloads are encrypted. What remains readable is the handshake, starting with the ClientHello. It carries the server name (SNI), the application protocols the client wants (ALPN), and a list of choices that depend on the TLS library and how the application configured it. Two different programs using two different libraries rarely produce identical ClientHellos; the same program on many machines usually does.
That gives defenders a way to say "these 40 connections come from the same kind of client" without decrypting anything.
JA3: five fields and an MD5
JA3, released by Salesforce engineers in 2017, concatenates five ClientHello fields as decimal values:
TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats
Values inside a field are joined with dashes, GREASE values are ignored, and the whole string is hashed with MD5. The server-side counterpart, JA3S, does the same with the ServerHello's version, chosen cipher and extensions.
Here is the ClientHello from the fictional sample capture in PCAP Parser, a TLS 1.3 session to g.api.mega.co.nz:
771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,
0-23-65281-10-11-35-16-5-13-18-51-45-43-27,29-23-24,0
JA3 = 7f805430de1e7d98b1de033adb58cf46
Two details stand out. The version is 771 (0x0303, TLS 1.2), even though the session is TLS 1.3: JA3 reads the legacy version field, and TLS 1.3 negotiates its real version in the supported_versions extension (43). And the extension list is taken in the order the client sent it, which is where JA3's weakness lies.
Why extension randomization broke JA3
In early 2023, Chromium browsers started permuting the order of TLS extensions in every ClientHello. The goal was to keep servers and middleboxes from depending on a fixed order, which makes the TLS ecosystem harder to change. Fastly measured the effect: with around fifteen extensions, the number of possible orders is so large that practically every connection gets a new JA3.
The browser did not change what it offers, only the order. But because JA3 hashes the order, the fingerprint stopped being a stable identifier for Chrome, Edge and other Chromium browsers. FoxIO's JA4 documentation cites this change as one of the reasons for the new design. A workaround used by some tools is to sort extensions before hashing JA3, but that produces a different value from the one in existing intelligence feeds.
JA4: sorted, truncated, readable
JA4 has three parts joined by underscores, a_b_c:
| Part | Content |
|---|---|
| a (readable) | protocol (t TCP, q QUIC, d DTLS), highest TLS version, d if an SNI domain is present or i if not, number of ciphers, number of extensions, first and last character of the first ALPN value |
| b | first 12 hex characters of the SHA-256 of the cipher list, sorted |
| c | first 12 hex characters of the SHA-256 of the extension list, sorted, without SNI and ALPN, followed by the signature algorithms in the order sent |
GREASE values are ignored throughout. The same sample session gives:
t13d1514h2_8daaf6152771_bc9a4605e104
Read the prefix: TLS over TCP, version 1.3, SNI with a domain, 15 cipher suites, 14 extensions, ALPN h2. The two other sessions in the sample, from the same client, give t13d1514h1_8daaf6152771_bc9a4605e104: only the ALPN part changes (http/1.1 becomes h1), and the two hashes are identical. That is the practical advantage: you can match on the whole fingerprint, on b and c only, or on the prefix, and see at a glance why two values differ.
Because extensions are sorted, Chromium's permutation does not affect JA4. And because the version comes from supported_versions, TLS 1.3 shows as 13 instead of the legacy 771.
On licensing: the JA4 TLS client fingerprint is published under the BSD 3-Clause licence, while the other methods of the JA4+ family use the FoxIO License 1.1. Check the repository before building JA4+ into a commercial product.
JA3 vs JA4 at a glance
| JA3 | JA4 | |
|---|---|---|
| Published | 2017, Salesforce | 2023, FoxIO |
| Fields | version, ciphers, extensions, curves, point formats | protocol, version, SNI type, counts, ALPN, ciphers, extensions, signature algorithms |
| Order | as sent | ciphers and extensions sorted |
| Hash | MD5 of the whole string | truncated SHA-256 for two parts, readable prefix |
| TLS 1.3 version | legacy field (771) | highest supported_versions (13) |
| Stable under extension randomization | no | yes |
| QUIC | not defined | defined (q prefix) |
How defenders use TLS fingerprints
Cluster the clients in a capture
Group TLS sessions by JA4 and count hosts per value. In a typical office network, most sessions come from a handful of browser and operating system stacks. A fingerprint seen on one workstation only, towards destinations nothing else talks to, deserves a closer look.
Spot mismatches
If HTTP traffic from a host claims to be a browser in its user agent, but the host's TLS sessions carry a fingerprint typical of a scripting language library, something other than the browser is making connections. The same reasoning applies to a server that suddenly originates TLS with a new stack.
Pivot with intelligence, carefully
Threat-intelligence platforms and vendor reports publish fingerprints associated with specific tools. Matching one is a lead, not a verdict. Combine it with the SNI, the server's JA3S, the destination's reputation, timing and host evidence. Always record which fingerprint variant a feed uses (raw JA3, sorted JA3, JA4).
Baseline your environment
Build a list of the fingerprints normally seen on your network, per host role. New values then stand out without needing any external list.
Limits you should know
- Not unique to malware. Every program that uses the same library with the same settings has the same fingerprint. Windows' built-in TLS stack, for example, is shared by many applications.
- Imitation is possible. Libraries exist that reproduce a browser's ClientHello. A browser-like fingerprint does not prove a browser.
- Encrypted Client Hello. With ECH (RFC 9849), the real ClientHello, including the real server name, is encrypted inside an outer ClientHello that carries innocuous values. Observers fingerprint the outer message and see a public name, not the actual destination.
- QUIC. HTTP/3 runs over QUIC, where the ClientHello sits inside encrypted QUIC packets. JA4 defines a
qvariant, but a tool has to decode QUIC to compute it; PCAP Parser does not decode QUIC yet.
Seeing JA3 and JA4 in a capture
PCAP Parser computes JA3 (string and MD5), JA4 and JA3S for each TLS session it finds on TCP, and shows them with the SNI, ALPN, offered and negotiated version in its TLS tab. Filter on a fingerprint to list every session that shares it, then export the view. The walkthrough shows the TLS view, and the tools comparison lists other tools that compute these fingerprints. For the name-resolution side of the same investigation, continue with DNS analysis in a pcap.
FAQ
What is the difference between JA3 and JA4?
JA3 is an MD5 hash of five ClientHello fields in the order the client sent them. JA4 is a three-part, partly readable fingerprint that sorts ciphers and extensions before hashing them with truncated SHA-256, and records protocol, TLS version, SNI presence, counts and ALPN in clear text.
Why did JA3 stop working for Chrome?
Since early 2023, Chromium browsers randomize the order of TLS extensions in each ClientHello. JA3 hashes the extensions in the order sent, so the same browser produces a different JA3 on almost every connection. JA4 sorts extensions first, so its value stays stable.
Does a TLS fingerprint identify malware?
No, it identifies a TLS client implementation and configuration. Many unrelated programs share the same library and therefore the same fingerprint. Use fingerprints to cluster and prioritise, and confirm with destination, timing, host evidence and other indicators.