what is TLS fingerprinting and why do anti-bot systems use it?

TLS fingerprinting is a technique anti-bot systems use to identify what software is making an HTTPS request, even before the request reaches the application layer. it works by hashing the client’s TLS handshake parameters into a signature (JA3, JA4, or HTTP/2 fingerprint). a Python requests call has a wildly different fingerprint than a Chrome browser, and anti-bot systems block on that mismatch alone. understanding TLS fingerprinting is the difference between scrapers that survive and scrapers that get blocked instantly.

how a TLS handshake works

every HTTPS connection starts with a TLS handshake. the client sends a “ClientHello” message that lists which ciphers, extensions, and protocols it supports. the server picks one and responds.

the order of those ciphers and extensions is not random. it’s determined by the TLS library the client uses (OpenSSL, BoringSSL, NSS, etc.). Chrome uses BoringSSL with a specific order. Python’s ssl module uses OpenSSL with a different order. curl uses OpenSSL too, but configures it differently.

these differences are mathematically deterministic. you can hash the entire ClientHello into a short string and that string will be the same every time the same software connects. that string is the TLS fingerprint.

JA3, JA4, and what they actually contain

JA3 is the original TLS fingerprint, published by Salesforce in 2017. it concatenates these fields from the ClientHello and MD5-hashes them.

SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat

example JA3: 771,4865-4866-4867,0-23-65281-10-11-35,29-23-24,0. MD5: e7d705a3286e19ea42f587b344ee6865.

JA4 (2023) is the modern replacement. it’s longer, more granular, and harder to spoof. it includes the ALPN protocol (h2, http/1.1), TLS extension count, and a sorted cipher list.

example JA4: t13d1516h2_8daaf6152771_b186095e22b6.

major anti-bot vendors (Cloudflare, Akamai, DataDome, PerimeterX) all check JA4 in 2026. some still check JA3 as a secondary signal. the Akamai bypass guide and DataDome bypass guide cover how each vendor uses these.

HTTP/2 fingerprinting (the second layer)

HTTP/2 has its own fingerprint, separate from TLS. the protocol lets the client configure SETTINGS, WINDOW_UPDATE values, and PRIORITY frames. each browser ships a specific combination, and the order matters.

a typical HTTP/2 fingerprint looks like:

1:65536,3:1000,4:6291456,6:262144|15663105|0|m,a,s,p

Chrome on Windows has a different fingerprint than Chrome on Mac. Firefox has a different one than Chrome. Python’s httpx with HTTP/2 has a fingerprint that screams Python.

modern anti-bot systems combine TLS + HTTP/2 + user agent. if your user agent says Chrome but your TLS and HTTP/2 fingerprints say Python, you get flagged immediately.

why this kills basic Python scrapers

a vanilla Python scraper using requests has a JA3/JA4 that matches no real browser. the same is true for urllib, httpx, Go’s net/http, and Node’s https module.

# this fails on any modern protected site
import requests
r = requests.get('https://target.com')  # blocked by TLS fingerprint

even if you set a perfect User-Agent, randomize timings, and use a residential proxy, the TLS fingerprint gives you away in the first packet. anti-bot systems can drop the connection before the application even sees it.

setting headers doesn’t help. headers are application-layer; TLS fingerprinting happens at the transport layer below them. for the broader fundamentals, our Python scraping guide explains where this fits.

how scrapers bypass it

three approaches work in 2026.

use a real browser. Playwright, Puppeteer, or Selenium drive actual Chrome or Firefox, which sends real browser TLS fingerprints. slow but reliable. our headless browser guide covers when this is the right call.

use a TLS-impersonating client. the cleanest approach. libraries like curl_cffi (Python) and cycletls (Go) link directly to BoringSSL or build a custom OpenSSL with Chrome’s exact settings. you get Chrome’s TLS fingerprint with the speed of plain HTTP requests.

from curl_cffi import requests

# this looks like Chrome 120 to any anti-bot
r = requests.get('https://target.com', impersonate='chrome120')

curl_cffi is the most popular Python option. it supports Chrome, Edge, Safari, and Firefox impersonation profiles. set impersonate='chrome120' and you get the matching JA3, JA4, and HTTP/2 fingerprint automatically.

use a managed scraping API. services like Bright Data Web Unlocker, ScrapFly, and ZenRows handle TLS fingerprinting on their backend. you send a regular HTTP request to their endpoint and they relay it with a real browser fingerprint. costs more per request but eliminates all this complexity.

what about TLS rotation

curl_cffi profiles are static. every request with impersonate='chrome120' has the same fingerprint. for very tough targets that fingerprint by IP+JA4, this can create a detection signal because too many connections from your IP have the identical fingerprint.

newer libraries (rebrowser, hrequests) randomize across multiple profiles per session. realistically you only need this for the hardest targets (Akamai with bot management, Cloudflare Enterprise). for normal scraping, a single Chrome profile is fine.

TLS fingerprinting in mobile and OS layers

TLS fingerprints differ by OS too. Chrome on Windows has slightly different ciphers than Chrome on macOS or Android. high-end anti-bot systems cross-check the user agent’s claimed OS against the TLS fingerprint’s implied OS. a mismatch is a classifier signal.

curl_cffi handles this by exposing OS-specific impersonation profiles (chrome120, chrome120_android, chrome120_ios). pick the one that matches your spoofed user agent.

faq

can I patch Python’s requests library to fake the fingerprint?
no. requests uses urllib3 which uses Python’s built-in ssl module, which uses OpenSSL with Python-specific settings. you’d need to recompile OpenSSL with BoringSSL settings, which is what curl_cffi already did. just use curl_cffi.

does using a residential proxy change my TLS fingerprint?
no. proxies relay traffic at the TCP/TLS layer; your client’s fingerprint passes through unchanged. residential proxies fix IP reputation, not TLS fingerprint. for the IP reputation side, see our IP reputation guide.

do anti-bot systems block specific JA4 hashes or patterns?
both. some maintain blocklists of known bot tool fingerprints (Python urllib3, Go default, curl). others use ML to classify fingerprints as browser vs non-browser. blocklists are easy to evade by switching libraries. ML-based detection requires a real-browser-like fingerprint to defeat.

what’s the difference between TLS fingerprinting and browser fingerprinting?
TLS fingerprinting happens at the network layer during the handshake. browser fingerprinting (canvas, WebGL, fonts, audio) happens at the JavaScript layer after the page loads. anti-bot systems use both. defeating one without the other still gets you blocked.

is curl_cffi enough on its own?
for medium-difficulty targets, yes. for Cloudflare Bot Management, Akamai with Bot Manager Premier, or DataDome at strict mode, you’ll also need to handle JavaScript challenges, CAPTCHA, and sometimes browser fingerprinting. TLS is the floor, not the ceiling.

can I detect TLS fingerprinting on a target site?
yes. send the same logical request from requests and from a real browser (curl –http2 with chrome ciphers). if the browser succeeds and Python fails with no useful error, TLS fingerprinting is involved. tools like browserleaks.com/tls show your current JA3/JA4 in real time.

conclusion

TLS fingerprinting is the silent layer of anti-bot detection that catches most rookie scrapers. your IP can be perfect, your headers can be perfect, your user agent can match Chrome exactly, and you’ll still get blocked because the TLS handshake gives you away in the first 200 bytes.

for Python scrapers, switching from requests to curl_cffi is the single biggest upgrade you can make. it costs nothing, runs at the same speed, and bypasses the basic TLS layer of every major anti-bot system. for harder targets, layer that with residential proxies, real browser automation, and a CAPTCHA solver as needed.

once you understand TLS fingerprinting, the rest of anti-bot defense makes sense. it’s all variations on the same theme: anti-bot systems look for any signal that suggests you’re not a real browser, and your job is to send signals that look exactly like a real browser at every layer.