Cloudflare expects compliance. The actual requirements depend on which Cloudflare security product/rule the particular website operator has enabled, and Cloudflare deliberately evaluates a collection of browser and request signals rather than exposing a simple pass/fail specification.
Execute JavaScript. Cloudflare’s challenges depend on client-side JavaScript. A browser with JavaScript disabled cannot complete them.
Accept and return the relevant cookies, particularly the cf_clearance cookie when a challenge is successfully passed. Cloudflare uses this cookie as evidence that the visitor has passed its client-side verification.
Allow Cloudflare’s challenge scripts and validation traffic to execute. Content blockers, script blockers, fingerprinting protection, and canvas/WebGL blockers can interfere.
Present a reasonably normal browser environment. Cloudflare evaluates browser-environment signals and looks for characteristics associated with automation.
Maintain a consistent network identity while solving the challenge. Cloudflare specifically says that a challenge issued from one IP and solved from another is invalid and can produce a challenge loop.
Not modify certain browser APIs in ways Cloudflare considers incompatible. Cloudflare explicitly says Challenges cannot support extensions that modify the User-Agent or Web APIs such as Canvas and WebGL.
Be a supported browser environment. Current Chrome, Firefox, Safari, and other major desktop/mobile browsers are supported; Internet Explorer, command-line clients such as curl/wget, and production browser automation frameworks are not. Heavily modified browser engines and embedded browsers have limited support.
But there’s a crucial distinction here. Cloudflare isn’t simply asking “is this a real browser?”
Its current Turnstile documentation says it performs small client-side challenges involving things such as:
- proof-of-work,
- proof-of-space,
- probing Web APIs,
- browser-quirk detection,
- human-behavior signals,
and uses those signals to adapt the challenge to the individual browser/request.
And its JavaScript Detection system similarly gathers client-side information and records the result in cf_clearance ← a cookie that Cloudflare can set in your browser after you successfully complete a Cloudflare security challenge.
Importantly, passing JavaScript Detection does not by itself mean that Cloudflare considers the visitor completely trustworthy. Other bot-detection heuristics can still produce a suspicious result.
So there isn’t a magic set of HTTP headers you can reproduce that means “Cloudflare-compliant browser.”
Cloudflare’s documentation describes the purpose as distinguishing legitimate human visitors from automated or malicious traffic. But the mechanism is necessarily probabilistic. Cloudflare says explicitly that a challenge can be triggered by things including:
*IP threat/reputation,
*bot-detection signals,
*WAF rules configured by the site owner,
*Browser Integrity Check,
*network characteristics,
*browser configuration,
*extensions,
*VPNs/proxies, etc.
Consequently, “complies with the browser requirements” and “is accepted by Cloudflare” are not equivalent propositions.
A completely legitimate browser can fail because, for example, its privacy configuration changes the signals Cloudflare expects. Cloudflare itself acknowledges that extensions, developer-tools overrides, device emulation, VPNs/proxies, and embedded browsers can alter the signals it receives.
And Cloudflare explicitly acknowledges another important point: JavaScript Detection can fail for legitimate reasons such as network problems, ad blockers, disabled JavaScript, or native/mobile application contexts.
