The __cf_bm Cookie vs cf_clearance: Cloudflare's Bot Cookies

__cf_bm is the cookie Cloudflare sets on visitors to sites that use Bot Management or Bot Fight Mode. It carries information Cloudflare uses to calculate its bot score (and, with Bot Management’s Anomaly Detection, a session identifier), it is encrypted so only Cloudflare can read it, and it expires after 30 minutes of continuous inactivity. It is not a pass: the cookie that proves a visitor passed a challenge is cf_clearance, which a challenge sets and a site’s Challenge Passage setting times out.

This article compares the two, lists the other cookies Cloudflare may set on an automated client, and says how a scraper or test suite should treat them. Automate only sites you are allowed to: see responsible captcha automation.

What __cf_bm contains and when it is set

Cloudflare’s cookie reference, checked on 1 October 2026, says:

• Where: “Cloudflare places the __cf_bm cookie on end-user devices that access customer sites protected by Bot Management or Bot Fight Mode.”
• What: “information related to the calculation of Cloudflare’s proprietary bot score and, when Anomaly Detection is enabled on Bot Management, a session identifier.”
• Privacy: “The information in the cookie (other than time-related information) is encrypted and can only be decrypted by Cloudflare.”
• Lifetime: “This cookie expires after 30 minutes of continuous inactivity by the end user.”
• Switching it off: “You can disable the __cf_bm cookie using the bm_cookie_enabled field via the API.”

The same page says every cookie it lists is “strictly necessary to provide the services requested by our customers, unless otherwise stated”, which is why sites rarely ask consent for it.

So a site on the Free plan with Bot Fight Mode switched on can set __cf_bm as readily as an Enterprise site with Bot Management. Its presence tells you bot detection runs on that site; it says nothing about whether you were challenged or passed.

__cf_bm vs cf_clearance

Cloudflare’s clearance page says a cf_clearance cookie “proves to Cloudflare that the visitor is a verified human and has passed Cloudflare’s client-side verifications”, and is “securely tied to the specific visitor and device it was issued to, preventing reuse across machines”. Nothing like that is said of __cf_bm: it feeds the score that decides whether a rule challenges you, while cf_clearance is what lets you through once you have been challenged.

Both come with modern attributes. Cloudflare sets cf_clearance with SameSite=None; Secure and the Partitioned attribute, and notes that “a clearance obtained in one top-level context is not reused in a different top-level context”. A clearance earned on a site in its own tab is not carried into another site that embeds it in an iframe.

The other Cloudflare cookies an automated client meets

None of them is a secret you can reuse elsewhere, and none of them replaces a clearance.

How an automated client should handle them

• Keep a cookie jar per session and send cookies back. A browser returns __cf_bm on every request until it expires. An HTTP client that drops cookies looks less like one, and on a site with Anomaly Detection loses the session the cookie identifies.
• One jar per identity. Cloudflare does not document what __cf_bm is bound to, so the safe rule is ours: keep each jar with the proxy address and user agent it was created with, as you must for cf_clearance. Don’t copy one session’s cookies into another.
• Don’t treat __cf_bm as progress. Having it means detection saw you, nothing more. If the site answers with a challenge page (HTTP 403 and the cf-mitigated: challenge header), you need a cf_clearance cookie, which only passing the challenge provides.
• Expect it to change. It is refreshed on the site’s responses and dies after 30 idle minutes, so read it from the jar each time rather than storing a copy.

This script loads a page with a persistent session and prints which Cloudflare cookies the site set, so you can see what a site uses before you automate it:

import requests

CLOUDFLARE = {"__cf_bm", "cf_clearance", "_cfuvid", "__cfruid", "__cflb", "__cfseq"}


def cloudflare_cookies(url):
    with requests.Session() as session:
        response = session.get(url, timeout=30)
        print(response.status_code, response.headers.get("cf-mitigated", "-"))
        for cookie in session.cookies:
            name = cookie.name
            if name in CLOUDFLARE or name.startswith(("cf_chl_", "__cfwaitingroom")):
                print(f"{name:20} domain={cookie.domain} expires={cookie.expires}")


cloudflare_cookies("https://shop.example.com/")

A __cf_bm in the output tells you Bot Fight Mode or Bot Management is on; a 403 with cf-mitigated set to challenge tells you a rule challenged this request.

Where ZeroCaptcha fits

When a site answers with a challenge page, ZeroCaptcha’s challenge task passes it through your own proxy and returns the cf_clearance cookie with the user agent it is bound to. Put that cookie in the same jar as the site’s other cookies, send the user agent with every request, and use the same proxy: the site then sets __cf_bm on your session as it would for a browser. The steps are in Cloudflare WAF and 5-second challenges and on the Cloudflare WAF and 5-second challenge solver page. ZeroCaptcha does not produce __cf_bm itself: that cookie comes from the site.

Sources

• Cloudflare: Cloudflare cookies (checked 1 October 2026).
• Cloudflare challenges: clearance (checked 1 October 2026).
• Cloudflare WAF: SameSite cookie interaction with Cloudflare (checked 1 October 2026).
• Cloudflare challenges: JavaScript detections, for the 15-minute cookie lifespan (checked 1 October 2026).
• Cloudflare challenges: detect a challenge response (checked 1 October 2026).
• Cloudflare: Error 403 (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.