See your JA3, JA4 & HTTP/2 fingerprint — the way anti-bot systems see it.

What is a browser fingerprint?

A browser fingerprint is a set of device, network, and software signals a website can read from your client to identify it — without using cookies. Two broad families exist. Passive fingerprints come from data you send just by connecting: the TLS ClientHello, HTTP/2 SETTINGS frame, IP, and headers. Active fingerprints are gathered with JavaScript: canvas, WebGL, fonts, audio context, screen geometry. Anti-bot systems combine both into a stable identifier that survives proxy rotation, incognito mode, and clearing cookies — which is exactly why a lone "rotate the User-Agent" change rarely matches what a modern WAF actually measures.

What is JA3?

JA3 is a fingerprint of the TLS ClientHello — the first packet your client sends on every HTTPS connection. It hashes (MD5) five fields concatenated in order: TLS version, cipher suites, extensions, elliptic curves, EC point formats. Because each TLS library (OpenSSL, BoringSSL, NSS, Schannel, rustls, Go crypto/tls) builds the ClientHello slightly differently, the resulting hash is a strong tell about which client you're using — even if your User-Agent says otherwise. JA3 was published by Salesforce in 2017 and is used in Suricata, Zeek, and most commercial anti-bot vendors. Its weakness: post-Chrome-110 extension shuffling and GREASE values broke JA3's stability for real browsers, which is why JA4 was created.

What is JA4?

JA4 is the 2023 successor to JA3 from FoxIO. It fixes two big problems: it sorts extensions before hashing (so Chrome's extension shuffling no longer changes the fingerprint), and it explicitly covers TLS 1.3 features JA3 didn't — ALPN, signature algorithms, supported versions. The format is human-readable: t13d1516h2_8daaf6152771_b0da82dd1658 means TLS 1.3, 15 ciphers, 16 extensions, ALPN h2, then a hash of the sorted ciphers and a hash of the extensions plus signature algorithms. Anti-bot vendors are migrating from JA3 to JA4 throughout 2024–2025.

How anti-bot systems use TLS fingerprints

Major bot-management vendors score the TLS fingerprint as one of their highest-weighted signals. A common diagnostic pattern: a client sends User-Agent: Mozilla/5.0 ... Chrome/128 but the JA3 hash is cd08e31494f9531f560d64c695473da9 — the well-known Python requests fingerprint. That UA/JA3 mismatch is the kind of inconsistency security tooling flags, and it explains why a plain HTTP client behaves differently from a browser even with a matching User-Agent header. Real browsers send 15+ ciphers and 14+ extensions; OpenSSL clients send a distinct set in a different order, so the two are easy to tell apart.

Why clients produce different JA3/JA4 values

The JA3/JA4 you measure is determined by the TLS library underneath your client, not by the application. A few common cases developers run into when debugging fingerprint mismatches:

TLS-impersonation libraries

Tools like curl-impersonate, tls-client (Go), and the curl_cffi Python binding rebuild the ClientHello to match a specific browser profile, so their JA3/JA4 reflects that browser rather than the default OpenSSL shape. Useful to know when a fingerprint reading does not match the underlying language runtime.

Real browser engines

Playwright and Selenium drive actual Chrome/Firefox/Safari binaries, so the TLS layer is genuine browser TLS and the JA3 matches that browser by definition. The fingerprint you see is simply the real engine's ClientHello.

Where Scrappey fits

For authorised data collection, Scrappey's requestType: "browser" mode runs requests inside a real Chrome with managed proxies — so TLS fingerprint, HTTP/2 settings, and IP reputation come from a genuine browser environment. free demo trial to try it.

TLS fingerprinting vs. browser fingerprinting vs. IP reputation

FAQ