By Byteprint · Updated
Byteprint technical guide
JA3 vs JA4: reading TLS client fingerprints
Both summarize how a client starts a TLS connection. The useful distinction is what they preserve, what they normalize, and what evidence you still need before naming the software behind a request.
The ClientHello is separate from the User-Agent
A TLS client advertises capabilities in its ClientHello before the encrypted application exchange. Those choices reflect its TLS library and configuration. An HTTP User-Agent is a separate application header: changing its text does not by itself change the TLS handshake.
Read the protocol definitions in RFC 8446’s ClientHello section and RFC 9110’s User-Agent section. Fingerprints summarize selected characteristics; they are not the full handshake.
What changes between JA3 and JA4?
| Property | JA3 | JA4 client fingerprint |
|---|---|---|
| Output | One 32-character MD5 hash | A readable prefix and two truncated SHA-256 hashes |
| Extension order | Preserved in the input | Sorted for the extension hash |
| GREASE | Excluded | Excluded |
| Readable context | Requires the unhashed input | Transport, version, SNI marker, counts, ALPN marker |
| Client identity | Requires reference evidence | Requires reference evidence |
JA3 serializes the ClientHello version, cipher suites, extensions, supported groups, and point formats before hashing. See the original JA3 algorithm. JA4 sorts ciphers and extensions but preserves signature-algorithm order in its final hash. Its technical specification defines the precise exclusions and encoding.
Sorting makes JA4 less sensitive to extension-order changes. Cloudflare describes the resulting reduction in fingerprint permutations in its JA3/JA4 documentation. A new cipher list, signature-algorithm list, or client configuration can still change the value.
A fingerprint match is evidence, not a verdict
Consider a request that advertises Chrome but whose JA4 differs from your Chrome reference. There are several questions to resolve before calling it impersonation: was the reference collected with the same client version, platform, configuration, and transport? Was the fingerprint observed at the same network boundary? Is a proxy establishing its own upstream connection?
A mismatch is a reason to investigate those differences. A match also needs context: applications can share a TLS stack, and software can deliberately imitate another client’s handshake. Neither value alone establishes whether the request is legitimate.
Byteprint’s database approach keeps known producers together, rather than assuming every fingerprint has one unique label. The capture methodology explains why software and environment records matter.
A practical investigation workflow
- Keep the original observation. Save the full JA4, timestamp, collection point, transport, and associated request context. Keep raw handshake evidence when your collection policy permits it.
- Check the format. Use the JA4 decoder to inspect the prefix. A truncated value or a JA4S server fingerprint needs different handling.
- Compare like with like. Record the fingerprinting implementation and version. Standard JA4 and exports that preserve original ordering are different representations; do not silently mix their hashes.
- Inspect every candidate. Ask which application, version, OS, and TLS stack actually produced each reference. An unsupported label or an old reference may be insufficient for the decision at hand.
- Corroborate before enforcement. Examine request behavior, authentication context, and your own application’s expected clients. Test a proposed rule against legitimate traffic before making it a blocking condition.
An absent catalog match means the available reference data did not identify the observation. It does not establish that the client is novel, safe, or hostile.
Can you convert a JA3 hash into JA4?
A JA3 hash does not contain enough information to reconstruct a JA4. If the original ClientHello is available, compute both with the appropriate implementations. If you only retained the hash, collect a new observation rather than inventing a conversion.
Where Byteprint fits
Byteprint is developing its own TLS fingerprinting representation and software reference data. The formats explained here are public formats; this guide does not describe Byteprint’s implementation or establish compatibility. The lookup API overview shows how that data can support identity checks. API access is planned for the private beta; the public decoder is usable without an account today.