Cloudflare Turnstile Token vs Cookie: Which One Do You Actually Need?

Someone posts the same question in a scraping Discord every week. "My solver gave me a token but the site still 403s me." Or the reverse: "I got the cookie, so why does the login form reject my submission?" Nine times out of ten the person grabbed one of the two things Cloudflare hands out and tried to use it where the other one belongs. They look similar from the outside. They're not interchangeable.

There are two separate values in play, and they come from two separate Cloudflare products. The Turnstile widget gives you a token called cf-turnstile-response. The full-page "Checking your browser" interstitial gives you a cookie called cf_clearance. Different source, different lifetime, different way to use it, different thing a solver returns. Mix them up and nothing works. Here's how to tell which one your target actually needs.

The two values, side by side

Before the explanation, the summary, because most people just want the table.

If that already told you what you needed, the code examples are further down. If not, keep reading, because knowing why they differ saves you the next three debugging sessions.

The token: proof you passed a widget

Turnstile the widget is that little box or invisible check sitting inside a login, signup, or contact form. When it decides you're human enough, it writes a long string into a hidden input named cf-turnstile-response. Your form submits that string along with the email, password, or whatever else the form carries. The origin server takes the value and calls Cloudflare's siteverify endpoint to confirm it's real before it trusts the request.

Three things define the token. It's tied to the sitekey it was minted for, so a token from one site won't validate on another. It's single-use, redeemed once at siteverify and dead after. And it's short-lived, expiring around 300 seconds after issue. It is not welded to your IP address, which is the detail that trips people up when they compare it to the cookie. We go deeper on the field and its lifecycle in the cf-turnstile-response token explained, and if you're hazy on what Turnstile even is, start with what is Cloudflare Turnstile and how it works.

The cookie: a pass to browse the site

cf_clearance is a different mechanism entirely. It comes from the full-page interstitial, the one that stalls for a few seconds with a spinner and the words "Checking your browser" before it lets you see anything. That challenge guards the whole site, not one form. When you clear it, Cloudflare sets a cf_clearance cookie in your browser, and from then on every request that carries the cookie skips the interstitial.

The cookie behaves nothing like the token. It's reusable, good for minutes or hours depending on the site's config. And it's bound to the IP and User-Agent that earned it. Send the same cookie from a different IP, or with a different UA string, and Cloudflare throws out the cookie and challenges you again. That binding is the whole point of the interstitial, so a stolen or shared cookie is worthless off its original context. The full write-up is in the cf_clearance cookie explained and how to reuse it, and the challenge itself in the Cloudflare 5-second challenge explained.

Which one does your target need?

Look at what's actually blocking you. There's a clean test.

• You can load the page fine, but a specific form or endpoint has a Turnstile widget on it. You need the token. Solve the widget, drop cf-turnstile-response into the form, submit. The rest of the site was never gated.
• You can't reach anything on the site because a "Checking your browser" page sits in front of the whole domain. You need the cookie. Clear the interstitial once, then reuse cf_clearance on every request from the same IP and UA.

Some sites do both. A storefront might put the interstitial in front of the domain and a Turnstile widget on its checkout form. In that case you need the cookie to browse and a fresh token each time you hit the widget. They don't substitute for each other. A valid token won't get you past the interstitial, and a valid cookie won't satisfy a form's siteverify check.

How a solver returns each one

Because they're two different things, a solving API returns them with two different task types. On Peak, the widget token comes from turnstiletaskproxyless (or turnstiletask if you want to pass your own proxy), and the clearance cookie comes from cloudflare5stask.

Getting the token

Send the page URL and the sitekey. You get a token back in about a second.

import requests

resp = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": "pk_your_api_key"},
    json={
        "task_type": "turnstiletaskproxyless",
        "url": "https://example.com/login",
        "sitekey": "0x4AAAAAAABxxxxxxxxxxxxx",
    },
    timeout=30,
).json()

token = resp["data"]["token"]   # "1.7Nm..."

# submit it immediately, before the ~300s window closes
requests.post("https://example.com/login", data={
    "email": "you@example.com",
    "password": "...",
    "cf-turnstile-response": token,
})

The response is {"success": true, "data": {"token": "1.7Nm..."}}. That token is an ordinary cf-turnstile-response value; the origin can't tell it apart from one a human's browser produced, because it isn't different. Copy-paste examples for driving a real browser are on the Python Turnstile integration page.

Getting the cookie

For the interstitial, send the URL. Peak clears the challenge and returns the cf_clearance cookie plus the request headers that go with it, including the User-Agent. You have to reuse all of it from the same IP.

import requests

resp = requests.post(
    "https://api.peak.fo/solve",
    headers={"X-API-Key": "pk_your_api_key"},
    json={
        "task_type": "cloudflare5stask",
        "url": "https://example.com/",
        "proxy": "http://user:pass@ip:port",
    },
    timeout=60,
).json()

data = resp["data"]
clearance = data["cf_clearance"]
headers = data["headers"]   # includes the matching User-Agent

# now browse the site, same proxy IP + same UA + the cookie
r = requests.get(
    "https://example.com/pricing",
    headers=headers,
    cookies={"cf_clearance": clearance},
    proxies={"http": "http://user:pass@ip:port",
             "https": "http://user:pass@ip:port"},
)

Notice the proxy appears in both calls. The cookie was earned on that exit IP, so every later request has to leave from the same one, carrying the same UA Peak handed back. Swap either and the cookie stops working.

The mistakes that cause 90% of the tickets

Almost every "it doesn't work" message comes down to one of these.

• Reusing a one-time token. The token is spent the moment the server redeems it at siteverify. One token per submission, no exceptions. If you're looping, solve inside the loop.
• Sitting on a token too long. It expires near 300 seconds. Solve right before the request that needs it, not minutes ahead in a batch.
• Using the cookie from a different IP or UA. This is the big one for cf_clearance. If you solve through Peak's proxy and then fire requests from your own server's IP, the binding breaks and Cloudflare re-challenges. Keep the IP and UA identical to what earned the cookie.
• Treating the cookie as single-use, or the token as reusable. Backwards on both counts. The cookie is reusable until it expires; the token never is. Cache the cookie, never cache the token.
• Solving the wrong thing. Throwing a token at an interstitial, or a cookie at a form. Check what's blocking you first, then pick the task type.

Quick recap

Token for a form behind a widget. Cookie for a site behind the interstitial. The token is one-time, short-lived, and sitekey-bound; submit it as a form field right after you solve. The cookie is reusable, IP-and-UA-bound; send it as a header from the same context that earned it. On Peak that's turnstiletaskproxyless or turnstiletask for the token and cloudflare5stask for the cookie, both back in about a second, both billed only on success.

You get 1,000 free solves with no card, so you can test which one your target needs before you commit to anything. Full numbers are on Peak's pricing page. One honest note: this is for automation, QA, and scraping public data you're allowed to reach. Respect the target's terms of service and robots rules, and keep it away from anything involving someone else's credentials.