What Is a JA3 Fingerprint? How the Hash Is Actually Built
A JA3 fingerprint is an MD5 hash computed from five fields in a TLS ClientHello message, producing a compact string that identifies a specific TLS client implementation regardless of the destination it's connecting to. Introduced by Salesforce researchers in 2017, it was the first fingerprint format to see wide adoption across CDNs, WAFs, and bot-management platforms, though its successor JA4 has since addressed several of its known weaknesses.
⚡ Key Takeaways
- JA3 hashes five ClientHello fields — TLS version, cipher suites, extensions, elliptic curves, and elliptic curve point formats — into a single 32-character MD5 string.
- It was introduced in 2017 by John Althouse and colleagues at Salesforce, and remains widely supported across security platforms today.
- JA3S is the server-side counterpart, fingerprinting the server's ServerHello response the same way JA3 fingerprints the client.
- JA3 has known false-positive and false-negative issues: unrelated clients can hash to the same value, and single-field differences (like one elliptic curve) can split what's really the same client into different hashes.
- JA4 is the direct successor, designed to fix JA3's normalization weaknesses while keeping the same core concept.
- A JA3 hash by itself doesn't identify a specific user or device — it identifies a TLS implementation, which many different users of the same software will share.
What Is a JA3 Fingerprint?
A JA3 fingerprint is a hash generated from specific fields of a TLS client's ClientHello message — the unencrypted first message a client sends when initiating a TLS handshake. Because it reads fields visible before any encryption or HTTP-layer data exists, it works identically regardless of what the client says about itself at the application layer, which is what makes it useful for detecting spoofed or automated traffic that claims to be something it isn't.
How a JA3 Hash Is Constructed
JA3 extracts five fields from the ClientHello and concatenates them, in order, separated by commas, with each field's internal list of values separated by hyphens: TLS version, cipher suites (in the order the client offers them), extensions, elliptic curves, and elliptic curve point formats. That concatenated string is then hashed with MD5 to produce the final 32-character fingerprint.
| Field | What it captures |
|---|---|
| SSL/TLS Version | The protocol version the client offers. |
| Cipher Suites | The full list of ciphers the client supports, in the order presented. |
| Extensions | Which TLS extensions the client includes and in what order. |
| Elliptic Curves | Supported elliptic curve groups for key exchange. |
| Elliptic Curve Point Formats | The point format encodings the client supports. |
JA3S applies the identical technique to the server's side of the handshake — the ServerHello message — producing a matching fingerprint for the server's TLS implementation rather than the client's, useful for identifying what server software or configuration is on the other end of a connection.
Where JA3 Is Used
JA3 is well supported across a wide range of security platforms today, including CDNs, WAFs, and dedicated bot-management vendors, which combine it with other signals for bot detection and mitigation, malware traffic identification, and threat research. Because JA3 has been public and widely documented since 2017, it has practical value as a shared reference: two security teams at different organizations can compare a JA3 hash against known threat intelligence and get a consistent answer about what client software produced it.
Present a real browser's JA3 fingerprint automatically
Nstdata Crawl's TLS stack matches known-good browser JA3/JA4 profiles, so scraping requests don't get flagged purely for handshake mismatch.
Try Nstdata Crawl →JA3 vs. Adjacent Concepts
JA3 is one specific, well-documented implementation of the broader TLS fingerprinting concept — the general practice of identifying clients from handshake characteristics — rather than a synonym for it. JA4 is JA3's direct successor, addressing normalization issues that caused JA3 to sometimes produce inconsistent hashes for what was functionally the same client, or coincidental matches between genuinely different clients. Where JA3 concatenates raw field values and hashes the result, JA4 restructures the fingerprint into labeled sections — covering metadata, ciphers, and extensions separately — specifically to reduce both false positives and false negatives compared to JA3's flatter approach.
Limits
JA3 has documented reliability issues: unrelated clients can legitimately produce the same hash if their TLS stacks happen to make identical choices, generating false positives when a fingerprint is treated as a unique identity. Conversely, a single differing field — one extra supported elliptic curve, for instance — can split what's really the same underlying client software across two different JA3 hashes, undercounting a client's actual traffic volume. A JA3 hash also identifies a TLS implementation shared by potentially thousands of users of the same software, not an individual device or person, so it should never be treated as personally identifying on its own.
Conclusion
JA3 turns five ClientHello fields into a single MD5 hash that identifies a TLS implementation independent of what a client claims about itself at the application layer — a genuinely useful signal, but one with known false-positive and false-negative behavior that its successor JA4 was specifically built to reduce. Neither format is a standalone identity check; both work best combined with other signals in a broader detection pipeline.
For scraping work that needs to present a consistent, real-browser JA3/JA4 profile rather than an obviously generic TLS stack, evaluate Nstdata Crawl against your target sites.
Further Reading
Sources
Try Nstdata Crawl for consistent JA3/JA4 profiles
TLS handshakes that match known-good browser fingerprints, out of the box.
Try Nstdata for Free →FAQ
Q: What fields make up a JA3 fingerprint?
Five fields from the ClientHello: TLS version, cipher suites, extensions, elliptic curves, and elliptic curve point formats, concatenated and hashed with MD5 into a 32-character string.
Q: What is JA3S?
The server-side counterpart to JA3, applying the same fingerprinting technique to a server's ServerHello response rather than a client's ClientHello, identifying server-side TLS implementations.
Q: Can two different clients have the same JA3 hash?
Yes. This is a documented limitation — clients with TLS stacks that make identical choices across all five fields will produce identical JA3 hashes even if they're genuinely different software.
Q: Why was JA4 created if JA3 already existed?
JA4 addresses normalization weaknesses in JA3 that caused inconsistent hashes for the same underlying client and coincidental matches between different clients, producing more reliable fingerprints overall.
Q: Does a JA3 hash identify a specific person or device?
No. It identifies a TLS implementation, which is typically shared by every user running the same browser version or software — it's not a personally identifying signal on its own.
Was this guide helpful?
Your choice is saved on this device.
