What Is TLS Fingerprinting (JA3/JA4) and How to Avoid It

Every HTTPS connection opens with a TLS handshake. The client speaks first, sending a ClientHello message that lists everything it supports: TLS versions, cipher suites, extensions, elliptic curves, and signature algorithms. Different software builds this list differently. Chrome offers one exact set in one exact order, Firefox offers another, and Python's requests offers a third that matches no mainstream browser at all.

TLS fingerprinting turns that ClientHello into a short, comparable identifier. Two well-known schemes do this: JA3 (a 2017 method from Salesforce) and JA4 (its 2023 successor from FoxIO). An anti-bot service computes the fingerprint from the raw handshake packet, then checks it against known-good browser fingerprints and known-bad automation fingerprints. No JavaScript, no cookies, no header parsing. Just the first packet.

The important part for scrapers: this signal is invisible to your application code. You cannot set it with a header, because it is decided by the TLS library your client links against, not by anything you pass to requests.get().

To understand the fingerprint, look at what the ClientHello actually carries. These are the fields both JA3 and JA4 read from:

The insight that trips people up: it is not any single value that gives you away, it is the exact combination and order. A real Chrome build always sends the same cipher list in the same sequence with the same extensions. A generic HTTP client sends a different combination, and that difference is enough to classify it.

If you want the background on where TLS sits relative to HTTP and SOCKS, our guide to proxy protocols covers the layers underneath this handshake.

JA3 concatenates five ClientHello fields into a single string, in this fixed order:

SSLVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats

Each field is a list of decimal values joined by dashes, and the five fields are joined by commas. A real string looks like this:

769,49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-21,29-23-24,0

That string is then hashed with MD5 to give the 32-character JA3:

cd08e31494f9531f560d64c695473da9

The hash is just a convenient label. The signal lives in the pre-hash string. If your cipher list or extension list differs from a browser's by one value or one position, you get a completely different MD5, and any detector with a browser allowlist sees an unknown fingerprint.

GREASE values (the reserved random values browsers inject per RFC 8701) are stripped before hashing, so they do not add noise. Everything else counts.

JA3 has a real problem on modern browsers. Starting with Chrome 110 in early 2023, Chrome randomizes the order of its TLS extensions on every connection. Because JA3 is order-sensitive, this means a single Chrome install produces a different JA3 on every request. JA3 became unstable for the world's most common browser, which is exactly the traffic scrapers most want to blend into.

JA4 was built to survive that. It is part of the JA4+ family (JA4 for the TLS client, JA4S for the server, JA4H for HTTP headers, JA4X for certificates). The TLS client fingerprint uses a readable a_b_c structure instead of one opaque hash:

t13d1516h2_8daaf6152771_02713d6af862

Breaking that apart:

The key change is in parts b and c: JA4 sorts the cipher and extension lists before hashing them. Chrome's per-connection extension shuffling no longer changes the fingerprint, because sorting cancels the shuffle out. JA4 also filters GREASE, SNI, and ALPN out of the extension hash so those do not skew it, and it adds QUIC support (q in part a) for HTTP/3.

There is a subtle detection angle here that most scraping guides miss. The d versus i marker in part a records whether you sent an SNI (a hostname) or connected to a bare IP with none. A scraper that skips SNI, or a proxy setup that connects by IP, produces an i fingerprint that no real browser ever generates, because browsers always send SNI. That single character can flag you even if your cipher list is perfect.

Default HTTP clients get flagged because their TLS stack is not a browser's TLS stack, and it was never trying to be.

• Python requests uses urllib3, which uses the system OpenSSL. Its ClientHello reflects OpenSSL's defaults: a cipher list and extension set that no shipping browser sends. Setting a Chrome User-Agent does nothing to the handshake.
• Node.js and axios use Node's TLS module, which again links OpenSSL with Node's own preferences. Recognizable as Node, not Chrome.
• Go net/http has a very distinctive Go TLS ClientHello. Anti-bot vendors keep a fingerprint for it specifically because Go is popular for scrapers.
• curl ships its own well-known fingerprint that maps straight to "command-line tool."

None of these are broken. They are just honest about what they are. The mismatch that gets you blocked is sending User-Agent: Chrome/124 over a TLS handshake that says Python-urllib3. Detectors love that contradiction, because a genuine Chrome user cannot produce it. Fixing headers alone never closes the gap, which is why header rotation guides only take you so far. TLS is a separate layer from the broader set of block signals like IP reputation, header order, and browser behavior.

Cloudflare, DataDome, Akamai, and PerimeterX all read the TLS fingerprint at the edge, during the handshake, before your request reaches an origin server. They use it in three ways:

1. Allowlisting. Traffic whose JA3 or JA4 matches a current browser passes the first gate cheaply. Traffic with an unknown or known-automation fingerprint gets extra scrutiny, a challenge, or an outright block.
2. Consistency checks. They cross-reference the TLS fingerprint against the HTTP layer. A Chrome JA4 paired with a User-Agent claiming Firefox, or with an HTTP/2 SETTINGS frame that Chrome never sends, is a contradiction that scores against you.
3. Rate and reputation grouping. Requests sharing one automation fingerprint get grouped and rate-limited together, even across rotating IPs. Rotating proxies does not help if every request carries the same tell-tale Go-http-client JA3.

The practical takeaway is that TLS fingerprinting is a filter you clear once per request shape, not per IP. Get the fingerprint right and you clear a gate that new proxies alone can never open.

There are three approaches that actually work. They trade off speed against realism.

Here is how the three client types compare on the signals that decide whether you get blocked.

The pattern is clear. Plain requests is fine against targets that do not fingerprint TLS, and it is the wrong tool the moment one does. curl_cffi covers most protected endpoints at high speed. A real browser or the Scraping API is what you reach for when the target also fingerprints JavaScript and behavior, not just the handshake.

Before you trust any fix, confirm what your client actually sends. Point each client at a TLS echo service that returns the fingerprint it observed, and compare:

# Plain requests: expect a urllib3 JA3 that no browser shares
import requests
print(requests.get("https://tls.peet.ws/api/all").json()["tls"]["ja3_hash"])

# curl_cffi impersonating Chrome: expect a Chrome-family JA3/JA4
from curl_cffi import requests as cffi
print(cffi.get("https://tls.peet.ws/api/all", impersonate="chrome").json()["tls"]["ja4"])

Open the same URL in your real Chrome and compare the JA4 to what curl_cffi reports. If the a part matches (same TLS version, cipher count, extension count, ALPN) you are impersonating correctly. If your scraper's JA4 shows i where the browser shows d, you are connecting without SNI and need to fix that first. Run this check again after every major browser release, because a template that matched last month can fall behind.