# JA4+ fingerprints explained: reading JA4, and JA4 vs JA3 > What JA4+ network fingerprints are, how to read a JA4 fingerprint, why JA4 replaced JA3, and how defenders use fingerprints with IP context. --- LLMS index: [llms.txt](/llms.txt) --- **In short:** JA4+ is a suite of network fingerprinting methods, created by FoxIO, that describe the software behind a connection from how it negotiates TLS, HTTP, SSH and TCP, without decrypting anything. A JA4 fingerprint stays the same for the same client software, can be read by a person, and replaced JA3 when browsers began shuffling their TLS extensions. Fingerprints identify software, not people, so they are most useful in context. ## What is JA4+? When a client opens an encrypted connection, the first messages of the handshake are sent in the clear: which TLS versions, cipher suites and extensions it supports, and in what form. Different software makes different choices. A fingerprint turns those choices into a short, comparable string. JA4+ covers several protocols and both ends of a connection, including: - **JA4:** the TLS client, from its Client Hello. - **JA4S:** the TLS server, from its Server Hello. - **JA4H:** the HTTP client, from its request headers. - **JA4X:** X.509 certificates, from how they were generated. - **JA4SSH:** SSH sessions. - **JA4T:** the TCP client, from its connection options. The methods are designed to be readable by people and machines alike, so analysts can compare fingerprints at a glance and tools can match on their parts. ## How do you read a JA4 fingerprint? Take `t13d1516h1_8daaf6152771_e5627efa2ab1`. It has three parts separated by underscores. | Part | Example | Meaning | |---|---|---| | Transport | `t` | `t` for TCP, `q` for QUIC | | TLS version | `13` | The highest version offered, here TLS 1.3 | | Server name | `d` | `d` if a domain name was sent (SNI), `i` if not | | Cipher suites | `15` | How many were offered | | Extensions | `16` | How many were offered | | ALPN | `h1` | First and last characters of the first application protocol offered, here HTTP/1.1; `00` if none | | Ciphers hash | `8daaf6152771` | Truncated SHA-256 of the sorted cipher suites | | Extensions hash | `e5627efa2ab1` | Truncated SHA-256 of the sorted extensions, leaving out the server name and ALPN extensions, followed by the signature algorithms in the order they were sent | GREASE values, reserved placeholders that some clients insert to keep servers tolerant of new values, are ignored throughout, in the counts and the hashes alike. The extension count includes the server name and ALPN extensions; the hash leaves them out because the first part already records them. Because the first part is readable, an analyst can tell a lot at a glance. This client offered TLS 1.3 over TCP, sent a server name, offered 15 cipher suites and 16 extensions, and asked for HTTP/1.1 rather than HTTP/2. A client that sent no server name would show `i` in place of `d`, and one that named no application protocol would end its first part in `00`: both unusual for a browser, which normally sends a server name and offers HTTP/2. Because the parts are separate, fingerprints that share a cipher list but differ in extensions can be found by matching on one part. ## JA4 vs JA3: why the change? JA3, published in 2017, concatenated the Client Hello fields in the order they arrived and hashed them with MD5. It worked well until browsers started randomising the order of their TLS extensions to discourage exactly this kind of ossification. From then on, a single browser produced many different JA3 values, and the fingerprint lost its meaning for the most common clients. JA4 sorts cipher suites and extensions before hashing, so the order no longer matters and the same software keeps the same fingerprint. It also keeps a readable prefix, covers QUIC and records whether a server name and which application protocol were sent. And JA4+ extends the idea beyond the TLS client to servers, HTTP, SSH, TCP and certificates. ## How defenders use JA4+ fingerprints - **Identify tooling.** Malware families, command-and-control frameworks, scanners and automation libraries each negotiate in their own way. A fingerprint known to belong to one of them is a lead in any log. - **Track infrastructure across address changes.** Attackers rotate IP addresses far more often than they rebuild their tooling. An uncommon JA4 and JA4S pair seen on a new address is a lead that links it to the old one. This matters most against [ORB networks](/guides/orb-networks/), whose addresses go stale almost as fast as they are reported. [Covert network flows](/solutions/intelligence/covert-network-flows/) carries JA4+ fingerprints on every flow, so encrypted sessions through covert networks can be grouped and tracked without decryption. - **Find automation behind residential addresses.** Requests that arrive from thousands of home addresses but share one non-browser fingerprint are one operation, not thousands of users. Combined with [residential proxy attribution](/guides/residential-proxy-detection/), the provider and the tooling appear together. - **Hunt in encrypted traffic.** Sessions can be grouped and searched by fingerprint without decrypting them, as in the [Webscout Observability Platform](/solutions/platform/), where a JA4+ fingerprint is also a pivot to related infrastructure. [On-demand honeypots](/solutions/intelligence/honeypot/) capture the JA4+ fingerprints of exploitation attempts against decoys of the systems you run. ## What fingerprints cannot do - **Identify a person or a device.** Many devices running the same software share a fingerprint. - **Prove intent.** A fingerprint shared by a malware family and a legitimate library needs more evidence. - **Resist deliberate imitation.** Some tools can mimic a browser's handshake. Fingerprints across several protocols, and context about the address and its history, make imitation harder to sustain. This is why a fingerprint is most useful with what has been observed with it, and with context on the addresses that present it. ## Where Webscout fits [JA4DB](/solutions/platform/ja4db/), the JA4+ fingerprint database, is built by Webscout for FoxIO, the creators of JA4+, and access is through FoxIO. Look up any JA4+ fingerprint in the interface or over the API and, depending on the data available, see what has been observed with it, an interpretation of its parts, statistics, classifications and history. Standard daily roll-ups take JA4DB into your own systems. The [Webscout Observability Platform](/solutions/platform/) supports JA4+ natively: fingerprints are carried on flows, including [covert network flows](/solutions/intelligence/covert-network-flows/), and can be searched and pivoted on beside IP context for every address.