How Cloudflare Uses JA3 and JA4 TLS Fingerprinting Markdown source

---
title: "How Cloudflare Uses JA3 and JA4 TLS Fingerprinting"
description: "How Cloudflare uses JA3 and JA4 TLS fingerprints in Bot Management, why JA4 replaced JA3, and why matching a hash is not enough."
kind: article
maturity: seedling
confidence: medium
origin: ai-drafted
author: "Agent"
directedBy: "krow"
tags: [tls, fingerprinting, cloudflare, bot-detection, ja4]
published: 2026-06-13
modified: 2026-06-13
wordCount: 1635
readingTime: 8
related: [ja4-vs-ja3, bot-detection-2026, tls-impersonation-library-comparison]
url: https://krowdev.com/article/cloudflare-ja3-ja4-bot-detection/
---
## Agent Context

- Canonical: https://krowdev.com/article/cloudflare-ja3-ja4-bot-detection/
- Markdown: https://krowdev.com/article/cloudflare-ja3-ja4-bot-detection.md
- Full corpus: https://krowdev.com/llms-full.txt
- Kind: article
- Maturity: seedling
- Confidence: medium
- Origin: ai-drafted
- Author: Agent
- Directed by: krow
- Published: 2026-06-13
- Modified: 2026-06-13
- Words: 1635 (8 min read)
- Tags: tls, fingerprinting, cloudflare, bot-detection, ja4
- Related: ja4-vs-ja3, bot-detection-2026, tls-impersonation-library-comparison
- Content map:
  - h2: Quick Reference
  - h2: Where Cloudflare Exposes JA3 and JA4
  - h2: Why Cloudflare Moved from JA3 to JA4
  - h2: JA4 Signals: the Fingerprint Becomes Context
  - h2: Matching JA4 Does Not Mean Passing Cloudflare
  - h2: Diagnostic Order
  - h2: Sources
- Crawl policy: same canonical content is exposed through HTML, Markdown, and llms-full; no crawler-specific content gate.

Cloudflare uses both JA3 and JA4 TLS fingerprints in Bot Management; JA4 is the more stable grouping signal for modern browsers because it sorts ClientHello extensions before hashing, while JA3 remains available for compatibility and coarse filtering.

## Quick Reference

| Detection layer | What Cloudflare inspects | Fingerprint / field it produces |
|---|---|---|
| TLS ClientHello | TLS version, cipher suites, extensions, supported groups, signature algorithms, SNI, ALPN | JA3 hash (`cf.bot_management.ja3_hash`) and JA4 (`cf.bot_management.ja4`) |
| JA4 aggregate intelligence | How that JA4 behaves across Cloudflare traffic over time: browser ratio, known-bot ratio, request ranks, networks/sites using it, cache/error behavior | `ja4Signals` / parsed JA signals used by Bot Management analysis |
| HTTP/2 layer | Cloudflare publicly cites HTTP/2 fingerprints; the general Akamai-format components are SETTINGS, WINDOW_UPDATE, PRIORITY, and pseudo-header order | HTTP/2 fingerprint (exact Cloudflare features not published) |
| HTTP headers and Client Hints | Header order, `sec-ch-ua`, `sec-ch-ua-platform`, User-Agent version, accept-language, fetch metadata | Internal request/header features (Cloudflare does not publish a JA4H deployment) |
| Egress and behavior | IP/ASN, residential-vs-cloud patterns, request timing, per-customer anomaly baseline | Bot Score, ML features, heuristics, detection IDs |

The key Cloudflare-specific point is the second row. A local JA4 calculator can tell you what one connection looked like. Cloudflare can compare that JA4 to aggregate behavior across its own traffic and then feed the result into Bot Management rules, Workers, Workers AI, custom models, and analytics.

For the broad detection order, keep [How Websites Detect Bots in 2026](/article/bot-detection-2026/) nearby. This page stays narrower: the Cloudflare field names, what changed from JA3 to JA4, and why a matching TLS fingerprint does not automatically clear the rest of the stack.

## Where Cloudflare Exposes JA3 and JA4

Cloudflare documents JA3 and JA4 under Bot Management additional configuration. Both are derived from the TLS ClientHello, which arrives before HTTP headers, cookies, JavaScript, or Turnstile. Enterprise Bot Management is the product tier called out for these fields. Cloudflare documents the JA3/JA4 fields and signals across Bot Analytics, Security Events and Security Analytics, the GraphQL Analytics API, Logs, WAF custom rules, Transform Rules, and Workers; the rule fields themselves require Enterprise Bot Management.

The two rule fields are concrete:

| Field | Meaning | Operational caveat |
|---|---|---|
| `cf.bot_management.ja3_hash` | The older JA3 SSL/TLS fingerprint for the connection | Still useful for odd libraries and legacy rules, but unstable for modern browser identification |
| `cf.bot_management.ja4` | The JA4 TLS client fingerprint for the connection | The practical modern field for browser-family grouping and rules |
| `ja4Signals` | Aggregated intelligence associated with a JA4 fingerprint | May be absent or null; treat it as enrichment, not a guaranteed field |

Cloudflare's docs explicitly warn that JA3/JA4 fields may be missing. That happens in real systems: not every request has the same TLS context, not every field is populated, and not every customer plan exposes every Bot Management signal. Rules that assume a fingerprint is always present are brittle.

The common Chromium-style JA4 prefix `t13d1516h2` is decoded separately in [JA4 fingerprint t13d1516h2](/snippet/ja4-fingerprint-t13d1516h2/). The important part for Cloudflare work is not memorizing the prefix; it is keeping the TLS identity coherent with HTTP/2, headers, Client Hints, proxy exit, and session behavior.

## Why Cloudflare Moved from JA3 to JA4

| Question | JA3 at Cloudflare | JA4 at Cloudflare | Why the difference matters |
|---|---|---|---|
| What is it? | MD5 hash of ordered TLS ClientHello fields from the 2017 Salesforce design | Human-readable prefix plus sorted SHA-256 hashes over ciphers, extensions, and signature algorithms from FoxIO's redesign | JA4 is more readable and more stable for modern browsers |
| Why did JA3 degrade? | Chromium ClientHello extension-order permutation (Chrome 110, 2023) makes ordered extension lists unstable; the same browser can produce many JA3 hashes | JA4 strips GREASE and sorts relevant lists before hashing | Cloudflare can group modern Chrome-like traffic without cardinality explosion |
| Does Cloudflare still expose it? | Yes: `cf.bot_management.ja3_hash` exists for Enterprise Bot Management rules and logging | Yes: `cf.bot_management.ja4` and JA4 Signals / Signals Intelligence exist | JA3 still exists, but JA4 is the practical modern signal |
| What is it good for? | Cheaply flags non-browser libraries and legacy or odd clients | Browser-family grouping, aggregate global intelligence, ML features, and rule features | JA3 is not useless; it is just no longer enough for browser identification |
| Can it be spoofed? | Some libraries can replay JA3-like profiles, but order sensitivity and missing HTTP/2/header layers still leak | A real browser or strong impersonation library can match JA4, but Cloudflare also checks H2, headers, IP, behavior, and per-customer baselines | Matching JA4 can be necessary for some flows, but it is not sufficient |

The full algorithm history belongs in [JA4 vs JA3: Why TLS Fingerprinting Migrated](/article/ja4-vs-ja3/). The Cloudflare version is shorter: JA3 remains available for compatibility and coarse filtering, while JA4 became the stable feature that can survive browser-side ClientHello randomization.

## JA4 Signals: the Fingerprint Becomes Context

Cloudflare's JA4 Signals announcement is the part most local fingerprint tests cannot reproduce. Cloudflare says it already used fingerprinting across DDoS protection, WAF, and Bot Management, then added JA4 fingerprints and inter-request signals to summarize how a fingerprint behaves over time. The blog describes aggregate analysis over the last hour of global traffic and, in its August 2024 announcement, reported more than 15 million unique JA4 fingerprints daily from 500M+ user agents and billions of IP addresses.

Signals Intelligence exposes aggregate context for a JA4 fingerprint: browser percentage, known-bot percentage, how many networks and sites use the fingerprint, request ranks and quantiles, cache behavior, and error behavior. That turns JA4 from a single string into a reputation-like feature. A fingerprint that looks browser-like in isolation can still be rare, geographically odd, tied to bad cache/error patterns, or inconsistent with the claimed headers.

That is why copying a ClientHello is not the same as copying a browser. If the TLS layer says Chrome, the HTTP/2 layer should say Chrome too; the header order should match; `sec-ch-ua-platform` should agree with the User-Agent; the proxy exit should not contradict the language and session history. For the HTTP/2 layer, [HTTP/2 Fingerprinting and the Akamai Format](/article/http2-fingerprinting-akamai/) is the deeper reference.

## Matching JA4 Does Not Mean Passing Cloudflare

Cloudflare Bot Management is not a JA4 lookup table. Cloudflare's residential-proxy ML write-up describes a model fed by request fingerprints, behavioral signals, global statistics, and residential/cloud-provider abuse features. Its per-customer defenses write-up describes analysts using HTTP/2 fingerprints and ClientHello extensions, plus anomaly models trained around a specific zone's normal traffic.

That has a practical consequence for authorized testing: if a stock client and a browser-like client receive the same 403 or challenge, the blocker may not be the TLS hash. It may be the proxy ASN, request path, rate pattern, per-customer anomaly model, missing cookies, JavaScript challenge state, Client Hints mismatch, or a bad connection-reuse strategy.

A mature HTTP client treats TLS identity as part of the transport key. Cache one transport for each coherent `(proxy, TLS profile)` combination so idle connections do not mix a Go-default ClientHello, a Chrome-like ClientHello, and different proxy exits. TLS impersonation should also be opt-in, not a global flag, because it adds dependency and trust surface.

If testing proves TLS and HTTP/2 are the failing layer, [TLS Fingerprinting with curl_cffi](/note/tls-fingerprinting-curl-cffi/) shows the implementation shape without turning this page into a library tutorial. If the question is which stack to evaluate, use [TLS Impersonation Library Comparison](/article/tls-impersonation-library-comparison/) instead of swapping libraries blindly.

## Diagnostic Order

| Step | Compare | Read the result as |
|---|---|---|
| 1 | Same request from normal egress and the intended proxy egress | Separates TLS problems from IP/ASN or regional policy problems |
| 2 | Stock TLS client versus browser-like TLS client on the same egress | Shows whether ClientHello shape changes the outcome |
| 3 | Browser-like TLS plus browser-like HTTP/2 and header order | Tests cross-layer consistency instead of only a hash |
| 4 | Stable session identity across retries | Catches churn where every request looks like a new device |
| 5 | Per-endpoint behavior at realistic timing | Distinguishes fingerprint failure from rate, path, and customer-specific anomaly signals |

The failure mode to avoid is silent fallback. A scanner or client that loses its proxy pool and direct-connects from a datacenter host has changed its identity more than any JA4 adjustment can repair. Explicit proxy selection, health scoring, sticky identity where sessions matter, and fail-closed behavior are part of the fingerprint story because Cloudflare sees the whole request, not only the TLS string.

## Sources

- [Cloudflare Bot Management JA3/JA4 fingerprints](https://developers.cloudflare.com/bots/additional-configurations/ja3-ja4-fingerprint/) — official docs for JA3/JA4 fields, Enterprise Bot Management availability, sorting, and missing-field behavior.
- [Cloudflare JA4 Signals](https://blog.cloudflare.com/ja4-signals/) — Cloudflare's announcement for JA4 fingerprints, inter-request signals, and global aggregate figures.
- [Cloudflare Signals Intelligence](https://developers.cloudflare.com/bots/additional-configurations/ja3-ja4-fingerprint/signals-intelligence/) — docs for JA4 aggregate fields such as browser ratio, known-bot ratio, ranks, networks, sites, cache, and error behavior.
- [Cloudflare `cf.bot_management.ja3_hash`](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/cf.bot_management.ja3_hash/) — Ruleset field reference for the JA3 hash.
- [Cloudflare `cf.bot_management.ja4`](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/cf.bot_management.ja4/) — Ruleset field reference for the JA4 fingerprint.
- [FoxIO JA4+ repository](https://github.com/FoxIO-LLC/ja4) — canonical JA4+ project and reference point for JA4, JA4S, JA4H, JA4T, JA4X, and JA4SSH.
- [FoxIO JA4 technical details](https://github.com/FoxIO-LLC/ja4/blob/main/technical_details/JA4.md) — details on JA4 parts, GREASE handling, sorted lists, ALPN, SNI, and hash construction.
- [Salesforce JA3 and JA3S](https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/) — original JA3 design and field set.
- [Chrome TLS extension permutation](https://chromestatus.com/feature/5124606246518784) — browser-side change that made ordered JA3 extension lists unstable.
- [Cloudflare residential proxy ML](https://blog.cloudflare.com/residential-proxy-bot-detection-using-machine-learning/) — source for Bot Management ML inputs beyond TLS, including request fingerprints and behavioral/global signals.
- [Cloudflare per-customer bot defenses](https://blog.cloudflare.com/per-customer-bot-defenses/) — source for analyst use of HTTP/2 fingerprints, ClientHello extensions, and per-zone anomaly models.