JA3 and JA4 TLS Fingerprinting Explained for Web Operators

What goes into the hash

A TLS ClientHello is a structured packet a few hundred bytes long. The mandatory fields — TLS version, cipher suite list, supported extensions, named groups, EC point formats — are filled in by the TLS stack, and the order in which they appear is generally consistent within a given library and version. Two installs of the same Chrome major version produce essentially the same ClientHello on the wire, while curl and Python and Go all produce visibly different ones.

JA3 captured that with a deceptively simple recipe: concatenate the TLS version, cipher suites, extensions, elliptic curves, and EC point formats — each as a comma-separated list of integers — join the lists with commas, and MD5 the result. The output is a 32-character hash you can log, cluster on, and join against threat-intel feeds.

JA4 keeps the spirit and fixes a number of practical issues with JA3: it's human-readable instead of opaque, it splits the hash into multiple fields so individual components are diffable, and it ignores GREASE values which would otherwise rotate the hash unhelpfully. It also adds companion hashes for HTTP/2 and HTTP/3, so a single client is described by JA4 (TLS) + JA4_H (HTTP) + JA4_X509 (the server certificate) — together far more resistant to forgery than JA3 ever was.

The pieces, one client at a time

The widget below lets you pick a representative client and inspect what goes into its JA3 / JA4. Watch how different the “cipher suites” line is between curl and Chrome — that single field alone is enough to tell “a browser” from “a script trying to look like one”.

Three patterns to memorise: browsers send GREASE, libraries don't; browsers ship a curated cipher suite list, libraries hand you whatever OpenSSL has compiled in; browsers prefer HTTP/2 ALPN, default Python / curl / Java clients don't. Knowing those three is enough to spot 90 % of unsophisticated bots from the ClientHello alone.

Reference: who fingerprints to what

The table below catalogues the families you're likely to see at the edge of a production service: real browsers, legitimate bots like crawler agents, common HTTP libraries, and the impersonation tools (utls, curl-impersonate, puppeteer-real-browser) attackers reach for when they actually try.

Using JA4 in production

Where to collect it

JA4 can be computed anywhere you can see the raw ClientHello: nginx with the ngx_http_ja4_module, HAProxy with the JA4 patch, Envoy via a TLS inspector filter, or off-box on the mirror port of a load balancer with Suricata, Zeek, or any of the dedicated JA4 collectors. Cloudflare, Akamai, Fastly, and most WAFs expose it as a request header you can log without running any TLS code yourself.

What to do with it

• Allow-list legitimate bots. Combine JA4 with reverse-DNS verification. Googlebot's JA4 + a reverse DNS in *.googlebot.com is enough to whitelist with confidence.
• Cluster anomalous traffic. A burst of requests sharing the same JA4 from thousands of residential IPs is almost always a botnet. The JA4 reveals the malware family the operator built the client around.
• Feed your fraud score. A “Chrome User-Agent” combined with a Python-shaped JA4 is the cheapest possible signal that a bot is lying about itself. It costs nothing to compute and is incredibly cheap to act on at the WAF layer.
• Hunt incidents. Threat-intel feeds publish JA4 hashes for known malware droppers, C2 frameworks, and credential stuffers. Cross-referencing your edge logs against those feeds catches campaigns that haven't shown up in IP-based reputation yet.

Don't block on JA4 alone

JA4 narrows the population, it doesn't identify individuals. Many bots now use tools like utls or curl-impersonate that ship hard-coded Chrome-shaped ClientHellos. The honest defensive stance is to combine JA4 with browser-level signals (HTTP/2 frame fingerprint, behavioural timing, attestation), not to make it the only gatekeeper.

How attackers evade

• Use a real browser. The unbeatable evasion is to run a real Chromium binary with Puppeteer or Playwright — JA4 is then indistinguishable from a human. Defending against that needs behavioural detection, not network signatures.
• utls / boringssl impersonation. A library that forges the ClientHello byte for byte. The give-away is downstream: HTTP/2 SETTINGS frames and frame ordering differ from the impersonated browser, and JA4_H catches that drift.
• Rotating fingerprints. Sophisticated bots rotate between several captured ClientHellos per session. Aggregating JA4 distribution over time, not per request, is what spots the pattern.