Support FAQ

JA3 vs. JA4 Fingerprinting: Format and Trade-offs

JA3 and JA4 both summarise a TLS client's ClientHello. They differ in what they expose and how they handle ordering. Neither one identifies a person, device or application with certainty.

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. It does not encode 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?

Question JA3 JA4
What is fingerprinted? TLS ClientHello TLS, QUIC or DTLS client hello
How is it represented? One MD5 hash Readable a section plus two truncated SHA-256 sections
Does order matter? Yes, for ciphers and extensions Ciphers and extensions are sorted; signature algorithms retain order
Are GREASE values included? No No
Is SNI represented? Its extension code can appear in the extension list Presence is explicit as d or i; the SNI value is not included
Is ALPN represented? Its extension code can appear in the extension list Two characters derived from the first ALPN value appear in a
Can components be compared separately? Not from the MD5 alone Yes; a, b and c are separate, and JA4_r can expose normalised lists

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 also deliberately discards that ordering evidence. If the order itself matters to an investigation, retain the packet or an original-order representation rather than relying on canonical JA4 alone.

Is JA4 always better than JA3?

No. JA4 is usually easier to inspect and less sensitive to ordering, while JA3 has a large body of historical logs and threat intelligence. A migration may need both for a period so old detections can be measured rather than translated by guesswork.

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 is not the whole JA4+ family

JA4 is the TLS client method. JA4S covers TLS server responses, JA4H covers HTTP clients and JA4X covers certificates. These are separate methods under the JA4+ name, not extra fields appended to core JA4. 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's JA4 Signals are another separate layer: inter-request aggregates calculated around JA4 fingerprints, not a synonym for JA4+.

Use either value as evidence, not attribution

A fingerprint match says two observed handshakes reduced to the same representation. It does not prove the same software, device or operator produced them. Shared TLS libraries create natural cohorts, clients can imitate common handshakes, releases drift, and proxies change what an observer sees.

Store the capture point, timestamp and relevant connection context with the fingerprint. Before blocking on a value, measure how broadly it appears in legitimate traffic and combine it with evidence tied to the action being protected.

Related Articles

AI Crawler User Agents

A practical reference for common AI crawler user agents, operators, purposes, and recommended Peakhour bot-management actions.

AI For Cybersecurity

AI For Cybersecurity explains the concept in the context of AI security, with practical checks and mitigation considerations for site operators.

AI Image Generation

AI Image Generation explains the concept in the context of AI security, with practical checks and mitigation considerations for site operators.

© PEAKHOUR.IO PTY LTD 2026   ABN 76 619 930 826    All rights reserved.