TLS Fingerprint (JA3)
A signature derived from how a client negotiates a TLS handshake, used to identify the software making a request - often via the JA3 hash.
A TLS fingerprint identifies the software behind a connection by the specific way it negotiates the TLS (HTTPS) handshake. The list of cipher suites, extensions, and parameters a client offers is characteristic of the library or browser it uses. JA3 is a popular method that hashes these values into a short signature representing the client.
This is powerful for bot detection because it operates below the application layer. You can set a perfect browser user agent and clean headers, but if your HTTP library negotiates TLS differently than a real Chrome browser, the JA3 fingerprint gives you away. Real Chrome, Firefox, and Safari each have recognizable TLS fingerprints; Python's requests and Go's net/http have their own, obviously non-browser ones.
Anti-bot systems maintain databases of known-good browser fingerprints and known-bad automation fingerprints. A request whose TLS fingerprint does not match its claimed user agent - Chrome header, non-Chrome handshake - is flagged as spoofed, often before the site even returns content.
Defeating TLS fingerprinting requires tools that mimic a real browser's handshake, such as curl-impersonate, specialized TLS libraries, or full browsers. Combined with residential proxies and matching headers, a browser-accurate TLS fingerprint is often what separates scrapers that get through from those that get blocked.
A hash of how your client says hello
Every TLS connection opens with a Client Hello, and that message carries a lot more than the hostname. It lists the cipher suites the client supports, the extensions it offers, the elliptic curves it knows and the formats it accepts, all in a specific order. That order is decided by the library, not by the user.
JA3 takes those fields, concatenates them and hashes the result. The output is a short string that identifies the client software rather than the person using it. Chrome on Windows produces one value, Firefox another, Python requests another, Go another. Two people using the same Chrome build produce the same JA3, which is the point: it identifies software, not identity.
For a defender this is close to free. It requires no JavaScript, no cookies and no waiting: the hash is available from the first packet, before your request is even parsed. That is why so many blocks land instantly on a client that has done nothing yet.
JA4 is the newer version of the same idea, harder to spoof by shuffling and more granular. The practical consequence is unchanged: your HTTP library announces what it is before it says what it wants.
What a proxy can and cannot do here
Our proxies move your traffic. They do not rewrite your TLS handshake, and no honest provider can claim otherwise:
Where the fingerprint comes from
requests / httpx / aiohttp -> Python TLS fingerprint, easily spotted
Go net/http -> Go fingerprint
curl -> curl fingerprint
curl-impersonate -> imitates a real browser build
Playwright / Puppeteer -> a real browser, so a real fingerprint
antidetect browsers -> real browser plus profile isolation- If a site blocks you instantly on a residential address but a browser on the same address works, the address was never the problem.
- For scraping protected targets, run a real browser or an impersonation library. Changing the User-Agent on a Python client does nothing about the handshake.
- Fingerprints follow browser versions. An impersonation library pinned to an old Chrome release becomes conspicuous once that build disappears from the wild.
- For account work use an antidetect browser. It gives you a genuine handshake plus separated cookies and storage, which the proxy alone cannot provide.
What JA3 does not tell a site
It does not identify you
Millions of people share a Chrome fingerprint. It identifies the software, which is exactly why an unusual one stands out.
It is not fixed by a proxy
The handshake is made by your client and passes through us unchanged. Any provider promising to hide it is describing something else.
It is not defeated by rotating addresses
The same fingerprint arriving from a hundred addresses looks like one tool with a hundred addresses, which is worse than one address.
Matching a browser is not enough on its own
Header order, HTTP/2 settings and behaviour have to agree with the handshake, or you have simply moved the contradiction one layer up.
See this in practice
Ready to use tls fingerprint (ja3)?
SotaProxy gives you access to rotating residential, mobile, datacenter, and ISP proxies. No minimum commitment.
Get started