JA3 vs JA4: TLS fingerprints, fields and uses

JA3 and JA4 summarise the first message a client sends when it starts a TLS connection. JA3 produces one hash from selected fields. JA4 keeps some readable details and uses two short hashes. Many clients can share the same fingerprint.

JA3 in one line

JA3 serialises five ordered groups as decimal values:

SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat

It removes GREASE values, preserves the remaining order and applies MD5 to the complete string. The output is a single 32-character hash. The Salesforce JA3 repository documents the algorithm and examples.

JA4 in one line

JA4 has three sections:

JA4 = a_b_c

The a section exposes transport, TLS version, SNI presence, cipher count, extension count and a short ALPN representation. b is a 12-character truncated SHA-256 hash of sorted cipher codes. c is a 12-character truncated SHA-256 hash of sorted extension codes plus signature algorithms in their original order.

The first character is transport: t means TLS over TCP, q means QUIC and d means DTLS. The following characters describe the TLS version. FoxIO's canonical example is:

t13d1516h2_8daaf6152771_e5627efa2ab1

The complete rules are in the JA4 technical specification.

What changed from JA3 to JA4?

JA4's sorting makes it stable when the only change is cipher or extension order. That is useful now that clients may vary extension order. It drops the original cipher and extension order. Keep the packet or a record of the original order when you need those details for an investigation.

Which format should your team use?

JA4 makes some connection details easier to read and handles changes in cipher and extension order. JA3 remains useful for matching older logs and known values. During a migration, keep both so you can check how your existing rules behave.

The right format also depends on the question. If the task is grouping handshakes despite reordering, JA4 is a good fit. If an existing investigation is keyed to known JA3 values, JA3 remains directly useful. If the task requires field-level comparison, store the raw handshake or JA4's raw form as well as the compact identifier.

JA4 and the JA4+ family

JA4 is the TLS client method. JA4S covers TLS server responses, JA4H covers HTTP clients and JA4X covers certificates. Each method has its own fields under the JA4+ name. Their licensing also differs: core JA4 is BSD 3-Clause, while FoxIO's licensing FAQ says the other JA4+ methods use the FoxIO License 1.1.

Cloudflare JA4 Signals add traffic measurements around JA4 fingerprints. These measures sit alongside the fingerprint.

Use fingerprints with request and account details

A fingerprint match means that two connections produced the same value. Applications can share TLS libraries, and clients can copy common connection settings. Software updates and proxies can also change the value you see.

Store the capture point, timestamp and relevant connection context with the fingerprint. Before blocking a value, check how often real users share it. Review it with the requested route, account history and login results.

Check a rule before you enable it

Choose a route, such as login or product search. Compare request rates, failed responses and successful user visits for each fingerprint. Start with logging, review shared browser values and then set a limit for the route.

Peakhour rate-limit zones can use TLS and HTTP/2 fingerprints, headers or cookies as keys. Choose the key around the traffic you need to control. Record how a rule affects both abuse and valid users.