Cloudflare Turnstile Pre-Clearance: How It Issues cf_clearance

Cloudflare Turnstile pre-clearance is a widget setting that makes Turnstile issue a cf_clearance cookie “in addition to the default Turnstile token” when a visitor passes. The cookie lets that visitor’s later requests on the same Cloudflare zone, API requests included, skip WAF challenge rules at or below the widget’s clearance level: Interactive (high), Managed (medium) or Non-interactive (low). It lasts for the zone’s Challenge Passage time, 30 minutes by default, and it is off unless the site turns it on.

Pre-clearance ties Turnstile, which any site can embed, to Cloudflare’s challenge pages, which protect sites whose traffic runs through Cloudflare. For the difference between the two, see Cloudflare challenge page vs Cloudflare Turnstile.

What pre-clearance does

A normal Turnstile widget produces a single-use token that the site verifies with siteverify (what a Cloudflare Turnstile token is). With pre-clearance on, Cloudflare’s docs say: “When you enable pre-clearance support on Turnstile, a cf_clearance cookie is issued to the visitor in addition to the default Turnstile token.” That cookie is the same one a challenge page sets, and it does what a challenge page’s clearance does: “The cf_clearance cookie enables visitors to bypass WAF Challenges on all subsequent requests on the zone, including API requests, based on the security clearance level set by the customer.”

The token keeps its own job. Cloudflare still requires the site to check it: “It is critical to enforce Turnstile tokens with the Siteverify API.”

Clearance levels

“All widgets have pre-clearance mode set to false and the security clearance is set to no_clearance by default.” A site owner turns it on per widget, in the Turnstile dashboard’s widget settings or through the Turnstile API’s clearance_level field, and picks a level:

Level	API value	Challenge rules the cookie skips
Interactive (high)	interactive	Non-Interactive Challenge, Managed Challenge and Interactive Challenge
Managed (medium)	managed	Non-Interactive Challenge and Managed Challenge
Non-interactive (low)	jschallenge	Non-Interactive Challenge only
None (default)	no_clearance	None

The Non-Interactive Challenge’s API value is js_challenge, which is why it is often still called the JS Challenge. The docs describe the cookie as a way past challenge rules; they say nothing about it lifting a Block rule. Cloudflare challenge types explains the three challenges, and Cloudflare WAF rules explained the rules that issue them. Pre-clearance is available on both the Free and Enterprise Turnstile plans.

Requirements

Turnstile alone works without Cloudflare’s CDN: “Turnstile can be used independently without requiring other Cloudflare services.” Pre-clearance does not, because the cookie is for a zone’s WAF. Cloudflare’s conditions:

• Use a registered Cloudflare zone, and “the hostname of the Turnstile widget matches the zone with the WAF rules”.
• “The clearance cookie cf_clearance will only be accepted on domains that match the widget’s configured hostnames, are registered as zones in your Cloudflare account, and have challenges enabled”.
• “The cf_clearance cookie cannot exceed the maximum size of 4096 bytes.”

Cloudflare also warns that a wrong setup backfires: “If pre-clearance is configured incorrectly, clearance cookies may become invalid and lead to additional challenge requests.” Repeated challenges of that kind are covered in Cloudflare challenge loop.

How long the cookie lasts

“Clearance cookies generated by the Turnstile widget will be valid for the time specified by the zone-level Challenge Passage value.” By default, “the cf_clearance cookie has a lifetime of 30 minutes. Cloudflare recommends a setting between 15 and 45 minutes.” When Cloudflare evaluates the cookie, “a few extra minutes are included to account for clock skew. For XmlHTTP requests, an extra hour is added”. And “The Challenge Passage does not apply to rate limiting rules.”

Content Security Policy: connect-src ‘self’

The cookie is set on the site’s own domain. “If you are using Turnstile in pre-clearance mode, Turnstile sets the cf_clearance cookie by doing a fetch request to a special endpoint in /cdn-cgi/” on the site’s own domain. “For this request to succeed, your connect-src directive must include 'self'.” That is in addition to the usual script-src and frame-src entries for https://challenges.cloudflare.com.

Why single-page apps and APIs use it

A challenge page is a full HTML page, which breaks requests made from code. Cloudflare: “This mechanism fails when the browser expects a non-HTML response, such as an AJAX or XHR (fetch) request.” Its recommendation: “To ensure your API calls are protected without breaking single-page applications (SPAs) or API integrations, Cloudflare recommends using Turnstile Pre-clearance.”

The flow is: the visitor passes the Turnstile widget on an ordinary HTML page; the widget sets cf_clearance; the app’s later fetch calls to endpoints guarded by a challenge rule carry the cookie and go through. Without the cookie, those calls would get a challenge response, which Cloudflare marks with the header cf-mitigated: challenge and serves as text/html, whatever the request asked for.

What pre-clearance means for an automated client

Automate only sites you are allowed to; see responsible captcha automation. With that settled, a site that uses pre-clearance changes three things for your client:

• The widget may hand out clearance. When a site’s Turnstile widget passes inside a browser you drive, that browser may receive cf_clearance too. Its later requests on the zone then skip challenge rules at or below the widget’s level, until the Challenge Passage time runs out.
• The cookie belongs to that browser. Cloudflare says the cookie “is securely tied to the specific visitor and device it was issued to, preventing reuse across machines.” Copying it into another machine or an HTTP client is not something to rely on. The docs do not list exactly which properties it is bound to.
• A token is not a cookie. As the docs describe it, the cookie is set by the widget’s own request to /cdn-cgi/ after the visitor passes. A token you get elsewhere and write into the form lets that form submission through siteverify, but it gives your client no cf_clearance. ZeroCaptcha’s Turnstile task returns a token only.

So if a site’s API endpoints answer your client with cf-mitigated: challenge after the form step, you are facing a challenge rule, not the widget. The cf_clearance cookie explained guide covers how that cookie behaves. For those pages, ZeroCaptcha’s challenge task passes the challenge through your proxy and returns the cf_clearance cookie with the user agent it is bound to. See the Cloudflare WAF and 5-second challenge solver page, and the Cloudflare Turnstile solver page for tokens.

Try it

The Cloudflare Turnstile pre-clearance demo carries a widget with pre-clearance on: solve it, and the page checks the token and whether your browser now holds cf_clearance.

Sources

• Cloudflare challenges: clearance (checked 1 October 2026).
• Cloudflare Turnstile: pre-clearance (checked 1 October 2026).
• Cloudflare Turnstile: Content Security Policy (checked 1 October 2026).
• Cloudflare challenges: challenge pages and detect a challenge response (checked 1 October 2026).
• Cloudflare challenges: Challenge Passage (checked 1 October 2026).
• Cloudflare Turnstile: plans (checked 1 October 2026).

The team that builds and runs the ZeroCaptcha API. Articles are drafted with AI tools, then checked against the API's code and the primary sources each one cites.