Cloudflare JA4 Fingerprint Reference

The field

cf.bot_management.ja4 is a rules-language field of type String. Cloudflare documents it as providing "an SSL/TLS fingerprint to help you identify potential bot requests".

The value is computed from the TLS ClientHello, the first message a client sends when opening an HTTPS connection. That makes it a property of the software connecting to you rather than something the client chooses to declare, which is the whole reason it is useful: a scraper can rewrite its User-Agent in a second, but changing its JA4 means rebuilding on a different TLS library.

Where it is exposed

Cloudflare's own documentation is the authority on the exact Workers accessor, which it describes as reachable through the Cloudflare Object rather than spelling out a property path. Take that one from their docs rather than from any blog post, including this one.

Reading the value

A JA4 looks like this:

t13d1516h2_8daaf6152771_806a8c22fdea

The first ten characters are readable without any lookup: transport (t for TCP, q for QUIC), TLS version, whether SNI was present, the cipher count, the extension count, and the first ALPN value. The two hashes that follow are truncated SHA-256 digests of the sorted cipher and extension lists, and cannot be reversed.

To decode a specific fingerprint field by field, paste it into the JA4 lookup tool, which runs entirely in your browser. For the full character-by-character specification, including the GREASE and empty-list rules and the raw JA4_r variant, the same page is the complete format reference.

Fingerprints you will see in Cloudflare

Prefixes only. Two clients can share a prefix and differ in the hashes, which is exactly how Playwright gives itself away against stock Chrome: same cipher hash, different extension hash.

Firewall rule syntax

Block a single tool fingerprint:

(cf.bot_management.ja4 eq "t12d1309h1_a3b4c5d6e7f8_1a2b3c4d5e6f")

Challenge anything matching a set of known scraper fingerprints on your API paths only:

(http.request.uri.path contains "/api/"
 and cf.bot_management.ja4 in {
   "t13d1310h2_aaaaaaaaaaaa_bbbbbbbbbbbb"
   "t12d1307h1_cccccccccccc_dddddddddddd"
 })

Scope by path or method wherever you can. A fingerprint that looks purely automated against your login endpoint may be a legitimate integration against a public one.

What not to do

Do not block browser-like fingerprints. Popular browsers share a very small number of JA4 values, so a single overly broad block can take out a large slice of real users at once. Restrict outright blocks to non-browser tool fingerprints, and pair them with a second signal wherever you can.

Do not treat a fingerprint as an identity. It identifies software, not an actor. Two unrelated visitors running the same Chrome build are indistinguishable by JA4 alone, which is why it works as a network-tier signal and fails as a user identifier.

Do not allowlist a crawler on its User-Agent. This is the failure JA4 is well placed to catch. Across our production detection corpus, roughly 46% of traffic claiming to be Googlebot and 55% claiming to be GPTBot did not come from those companies' published IP ranges. A User-Agent is a claim; the handshake is evidence.

If you are not on Enterprise

The field is gated, but the technique is not. JA4 is computed from the ClientHello, so anything terminating TLS can derive it: your own reverse proxy, an edge worker with raw handshake access, or a detection layer running alongside your application. WebDecoy computes spec-compliant JA4 from the raw ClientHello and correlates it into a persistent actor identity, then pushes rules into Cloudflare or AWS WAF on your behalf, which does not require you to have the field exposed in your own dashboard.

For the narrative version of all this, with worked examples of catching specific scrapers, see JA4 Fingerprinting: Detect AI Scrapers by TLS . For pushing rules automatically instead of maintaining them by hand, see Defeat IP Rotation: Block Bots by JA4 at the WAF.

Frequently Asked Questions