Cloudflare's managed challenge vs JS challenge vs interactive challenge

Someone sends a request to a Cloudflare-protected origin. Cloudflare decides the request is suspicious enough to interrupt. What happens next depends on a single configured action, and that action has a name: JS challenge, managed challenge, interactive challenge, or, until recently, CAPTCHA. Four words that look interchangeable in a firewall-rule dropdown and are not. One of them no longer issues a visual puzzle to anyone for any reason. One of them runs JavaScript and asks nothing of the user. One is deprecated and Cloudflare would prefer you stop selecting it. And the fourth, CAPTCHA, has been quietly replaced under the hood by something that shares almost none of its mechanics.

This post is about that taxonomy and nothing wider. Not the bot score, not the cf_clearance cookie internals, not the TLS fingerprint that feeds the decision in the first place. The question here is narrower and more often gotten wrong: given that Cloudflare has decided to challenge a request, what are the actual challenge types, when does each one fire, what does each one measure, and how do they relate to each other through the clearance level they grant? The names have shifted over five years, the defaults have changed, and the legacy CAPTCHA action still appears in older configs while no longer doing what its name says.

A sourcing note before we start. Cloudflare documents the challenge types, the clearance levels, and the cookie attributes in its developer docs and on its engineering blog, and those are the spine of this post. The orchestration internals, the contents of the encrypted challenge payload, and the exact signals each challenge weighs are not fully public. Where this post describes the wire format of the challenge platform it leans on independent research and observed traffic, and it says so at that point rather than dressing inference up as documentation. The dates, percentages, cookie names, and field names below all come from primary sources listed at the foot.

The sections walk from the outside in. First the firewall action that triggers a challenge at all. Then each of the four types in turn: JS challenge, managed challenge, interactive challenge, and the retired CAPTCHA. Then the clearance level each one grants and how a cookie issued by one type bypasses another. Then the orchestration layer all of them share. Then the historical arc, because the names only make sense once you know what each one was reacting to.

The action, not the challenge

The first thing to get straight is that “challenge” is an action a rule takes, not a thing a user always sees. In Cloudflare’s model a request flows through the WAF, custom rules, rate-limiting rules, and the bot-management engine, and any of those can resolve to an action. Block and allow are the obvious two. Between them sits a family of challenge actions, and selecting one of those is what arms the machinery this post describes. Bot Fight Mode and Super Bot Fight Mode issue challenges automatically; a custom WAF rule lets you pick the action by hand.

So when a site operator writes a rule like “challenge anything from this ASN that hits the login path,” the word “challenge” there is a placeholder for a specific type. In the modern dashboard the only challenge action Cloudflare wants you to choose is the managed one. The others still exist as selectable actions for backward compatibility and narrow edge cases, which is exactly why the taxonomy stays confusing. The dropdown outlived the reasons each entry was added.

What actually reaches the visitor when a challenge fires is an interstitial: an HTML page served in place of the origin response, carrying the JavaScript that runs the challenge. The visitor’s browser executes that script, the script talks back to Cloudflare’s challenge platform under /cdn-cgi/challenge-platform/, and if the result is good enough the browser is issued a clearance cookie and bounced to the original destination. Every challenge type shares that skeleton. What differs is how much the script measures, whether the user has to do anything, and what level of clearance a pass earns.

*Every challenge type shares the same skeleton: an interstitial serves JavaScript, the script reports back, and a pass issues a cf_clearance cookie. What differs is how much is measured and what level the cookie grants.*

JS challenge: the non-interactive baseline

The JS challenge is the oldest of the surviving types and the simplest to describe. Cloudflare’s docs now call it the non-interactive challenge, and the rename is the more honest name. When it fires, the visitor gets an interstitial that runs JavaScript, waits, and proceeds. There is no checkbox. There is no image grid. The only thing asked of the browser is that it execute the injected script and finish processing it, which the documentation describes as typically taking less than five seconds. That five-second wait is the famous “Checking your browser before you access…” page that a generation of users learned to sit through.

What it measures is deliberately limited. Cloudflare’s own description is that it makes the human-or-bot determination “based on the limited information attained from their browser signals via an injected JavaScript.” That phrasing matters. The JS challenge does not adapt. It runs a fixed battery of client-side checks, decides, and either passes or fails the browser. It is a gate that any environment capable of running the right JavaScript can clear and that any environment incapable of it cannot. A real browser running a real JS engine sails through. A bare HTTP client that does not execute JavaScript at all is stopped cold, because it never runs the script that would produce the token.

The practical consequence is that the JS challenge filters on capability, not on suspicion strength. It is binary. Either the client can run the challenge script in something that looks enough like a browser, or it cannot. There is no middle path where the challenge escalates because the client looks slightly off. For that escalation behaviour you want the managed challenge, which is the whole reason it exists.

JS challenge is still a selectable action and still useful in narrow cases, mostly compatibility ones where a managed challenge’s adaptive behaviour or its dependence on Cloudflare’s wider signal set causes friction. But for most rules Cloudflare’s documentation is blunt about steering operators away from it. The non-interactive challenge is the floor, not the recommendation.

One source of genuine confusion deserves a flag here. Cloudflare also ships a feature called JavaScript Detections, and it is not the JS challenge. JavaScript Detections is an invisible, always-on script injected into HTML responses as part of Bot Management. It runs on every request, asks the user nothing, and writes its verdict into a field named cf.bot_management.js_detection.passed that you then reference in your own rules. It issues a cf_clearance cookie too, which is part of why people conflate the two. The difference is that JavaScript Detections is a passive signal that populates a field; the JS challenge is an active interstitial that blocks the request until the script runs. One informs a rule. The other is a rule’s action.

Managed challenge: the adaptive one Cloudflare recommends

The managed challenge is the type Cloudflare wants you to pick, and it is the only one the modern docs recommend without caveats. Announced on the first of April 2022 by Reid Tatoris and Benedikt Wolters, it was the company’s answer to a problem it had been circling for years: the visual puzzle is a terrible test, but you cannot always tell in advance whether you need one. The managed challenge’s trick is to defer that decision. Instead of deciding up front whether to show a visual puzzle, it runs a non-interactive battery first and decides whether any interaction is needed based on what the browser does during the challenge.

The 2022 announcement is specific about the toolkit. A managed challenge runs “a series of small non-interactive JavaScript challenges” that gather signals about the visitor and the browser environment, and the post names the categories: proof-of-work, proof-of-space, probing for web APIs, and checks for browser quirks and human behaviour, plus machine-learning models trained on the behaviour of known CAPTCHA-solving services. Most visitors are cleared by these alone and never see anything but a brief spinner. Only when the signals stay ambiguous does the managed challenge escalate to asking the user to do something, and even then the something is a single interaction rather than a puzzle.

The numbers Cloudflare reported for the rollout are the strongest argument for the approach. Over the year leading up to the announcement, deferring the visual-puzzle decision cut the number of CAPTCHAs Cloudflare served by 91 percent, and the company set a goal of pushing CAPTCHA use below 1 percent of challenges by the end of that year. The visitor-facing payoff was a drop in average challenge time from 32 seconds to roughly one second, and human visitors were reported as 31 percent less likely to abandon a managed challenge than a CAPTCHA. The pitch was never that the managed challenge is harder to beat than a CAPTCHA. It is that for the overwhelming majority of legitimate humans it is invisible, and the puzzle is reserved for the residual cases where the signal genuinely warrants it.

*The managed challenge runs the silent battery first and only escalates to an interaction when the signal stays ambiguous. The reported 91 percent CAPTCHA reduction came from how rarely that escalation fires.*

The managed challenge is also the bridge to Turnstile. The interstitial managed challenge and the embeddable Turnstile widget run the same underlying machinery; Turnstile’s “managed” widget mode “functions similar to a Managed Challenge Page,” selecting a challenge from the same browser signals and presenting an interaction only if the traffic looks potentially automated. The difference is packaging. A managed challenge is something Cloudflare inserts in front of an origin it proxies. Turnstile is the same engine handed to you as a widget you embed in a form, validated server-side through a siteverify call. If you want the deeper mechanics of the embedded form, the Turnstile internals post covers the token and siteverify flow; here the point is only that managed challenge and Turnstile-managed are siblings, not cousins.

Interactive challenge: the deprecated middle

The interactive challenge is the type Cloudflare would like to forget. It is the one that asks the visitor to do something explicit: tick a checkbox, click a button, perform a small interaction so the challenge can probe further. In the taxonomy it sits above the JS challenge and below the old CAPTCHA, an interaction that is more than a silent wait but less than a visual puzzle. For a while it was the natural “show the user a box to click” action.

The managed challenge took its job. Because the managed type can escalate to an interaction on its own when the signal warrants it, a standalone interactive challenge is now mostly redundant: it forces an interaction unconditionally where the managed one would have made it conditional. Cloudflare’s documentation reflects this by recommending the managed challenge for essentially all WAF rules and steering operators away from selecting interactive or non-interactive directly unless a specific compatibility issue forces it. The interactive action still exists, still works, and still appears in older rule sets. It is just no longer the right default, and Cloudflare says so.

There is a naming trap worth defusing. “Interactive challenge” and “the interactive part of a managed challenge” are not the same thing, even though both end with the user clicking something. When a managed challenge escalates and shows a checkbox, that interaction is the managed challenge doing its job conditionally. The standalone interactive challenge is a separate action that goes straight to the interaction. The user experience can look identical in the moment. The decision logic behind it is different, and so, as the next section shows, is the clearance level the pass earns.

CAPTCHA: the type that no longer exists

The fourth historical type is the legacy CAPTCHA, and its current status is the most interesting in the set, because it is the one that has been hollowed out. For years a CAPTCHA action meant exactly what it sounds like: serve the visitor a visual puzzle, originally Google’s reCAPTCHA, then hCaptcha after the April 2020 migration, and make them solve it. As of late September 2023, that is no longer what happens. With the general availability of Turnstile, Cloudflare announced it had finished replacing every CAPTCHA it issued, and stated flatly that it “will never issue another visual puzzle to anyone, for any reason.”

So the CAPTCHA action did not get a final visual puzzle wired to a better solver. It got redirected to Turnstile-style detection. A rule that still says CAPTCHA, or an older integration that expected one, now resolves to the same non-interactive-first machinery as a managed challenge rather than to an image grid. The name survived in places. The puzzle did not. This is the single most counterintuitive point in the whole taxonomy: the type whose entire identity was “show a visual test” is now the one type guaranteed never to show one.

The reasons Cloudflare gave for killing the puzzle are worth stating because they explain why the managed challenge exists at all. The company’s case against CAPTCHA was that the test is bad on both ends. Humans abandon it about 15 percent of the time. Bots, meanwhile, beat it more reliably than people do; the GA post cites audio CAPTCHAs solved by automated systems at over 85 percent success while three-person human agreement on the same audio sat around 31 percent. A test that frustrates the people it is supposed to admit and waves through the machines it is supposed to stop is not a test worth keeping. The 2021 Cryptographic Attestation of Personhood experiment, with its hardware-key “I am human” flow built on WebAuthn, was an earlier swing at the same problem from a different angle. The managed challenge is the swing that landed.

*The CAPTCHA action outlived the puzzle. After September 2023 a rule that says CAPTCHA resolves to the same non-interactive machinery as a managed challenge.*

Clearance levels: how the types relate

The four types are not just four front ends. They sit in a hierarchy, and the hierarchy is enforced through the cf_clearance cookie that a passing visitor receives. Each challenge type sets a clearance level, and a cookie issued at a higher level bypasses challenges at that level and below, while a cookie at a lower level only clears challenges of its own kind. This is the part of the taxonomy that actually has teeth, because it determines whether passing one challenge gets you through the next.

Cloudflare’s clearance documentation lays out three levels. Interactive is the high level: a clearance cookie earned from an interactive challenge bypasses interactive, managed, and non-interactive challenges. Managed is the medium level: its cookie bypasses managed and non-interactive challenges, but not a standalone interactive one. Non-interactive is the low level, and its cookie only bypasses other non-interactive challenges. The ordering is intuitive once you see it. Passing the harder test buys you out of the easier ones; passing the easier test does not buy you out of the harder one.

*The clearance hierarchy from Cloudflare's docs. A cookie carries the level of the challenge that issued it, and only clears challenges at or below that level.*

Turnstile adds a pre-clearance dimension that maps onto the same three levels. A Turnstile widget can be configured to issue a clearance cookie for the wider zone, and the pre-clearance setting names the level it grants: interactive, managed, or jschallenge, with no_clearance as the default. Those values line up one-to-one with the three challenge clearance levels. Solve a Turnstile widget configured for managed pre-clearance, and the cookie you get clears managed and non-interactive challenges elsewhere on the zone, exactly as if you had passed a managed challenge directly.

How long that cookie lasts is a per-zone setting, not a fixed number. The clearance docs describe the cookie as valid for the time specified by the zone-level Challenge Passage value, which an operator configures. The widely cited default is on the order of tens of minutes rather than hours, and the older help material put it at 30 minutes, but the precise default has shifted over the years and the authoritative figure for any given zone is the Challenge Passage setting itself rather than a number quoted in a blog post. The cf_clearance cookie’s mechanics, its binding to the visitor, and its lifetime are their own subject; the cf_clearance cookie post covers issuance, scope, and lifetime in detail. For the taxonomy, the load-bearing fact is the level, not the duration.

The cookie’s attributes matter for one taxonomy-adjacent reason. Cloudflare sets cf_clearance with SameSite=None; Secure; Partitioned, which is what lets challenge state survive cross-site requests while complying with CHIPS, the cookie-partitioning standard. The Partitioned attribute means a clearance cookie issued inside a third-party context, such as a Turnstile widget embedded in someone else’s page, is keyed to the top-level site and is not shared across embedding sites. That is a deliberate scoping decision, and it changed how clearance behaves in embedded contexts compared with the cookie’s earlier, unpartitioned form.

The orchestration underneath

All four types run on one shared platform, and the platform is worth a look because it explains why the types feel so similar on the wire even when they behave differently. When a challenge fires, the interstitial does not carry the whole challenge inline. It bootstraps. Independent research into the challenge platform, the most-cited being the public scaredos/cfresearch notes, describes a first request to an orchestration endpoint under /cdn-cgi/challenge-platform/, something like .../orchestrate/chl_page/v1?ray=${ray_id}, that returns JavaScript responsible for generating a challenge ID and driving the subsequent exchange. The exact path segments have varied (h/b and h/g variants appear in observed traffic), and the bytes of the payload are encrypted, so the field layout below is inferred from that research and observed requests rather than from Cloudflare documentation.

What that research reports seeing is a client object the page exposes as window._cf_chl_opt, carrying fields such as the challenge ray (cRay) and a flag like cTplC when a custom challenge template is in use, followed by a POST back to the platform with an encoded payload keyed to the ray. The final submission to the protected origin carries fields the research labels md, and others tied to the managed-clearance result, with a structure indicating the clearance type granted. Treat those names as observed rather than blessed. Cloudflare does not publish the schema, it changes the obfuscation regularly, and the value of knowing the names is understanding the shape of the flow, not reconstructing it. The anatomy of that orchestration, including how the cf-chl pieces fit together, is the subject of the challenge platform post.

The reason the platform matters to the taxonomy is that it is the same skeleton under every type. A JS challenge, a managed challenge, an interactive challenge, and a post-2023 CAPTCHA action all bootstrap through the same orchestration, run JavaScript from the same platform paths, and end by setting a cf_clearance cookie. The differences are in what the script measures and what level it grants, not in the transport. That is why a packet capture of two different challenge types looks nearly identical until you decode what the payload is actually doing. The plumbing is shared; the policy is what varies.

It is also why the challenge types are not really separable from the signals that decide whether to fire them at all. The decision to challenge, and which level to demand, leans on Cloudflare’s bot score and the network and TLS fingerprints feeding it. A request that already looks clean on its TLS and HTTP/2 fingerprint may never see a challenge; a request that looks automated may be sent straight to an interactive one. The challenge type is the visible end of a pipeline whose interesting decisions happen earlier. The taxonomy here is the menu of responses, not the logic that chooses among them.

The arc that produced four names

The names only make sense in order. The JS challenge came first, as the original “make the browser prove it can run JavaScript” gate, and it was binary and unadaptive by design. The CAPTCHA action sat above it as the heavy hammer, the visual puzzle for when JavaScript alone was not enough, and for years it ran on reCAPTCHA until the April 2020 economics and privacy concerns pushed Cloudflare to hCaptcha. The interactive challenge filled the awkward middle, an explicit click that was more than a wait and less than a puzzle. Four actions, four points on a spectrum from “do nothing visible” to “solve an image grid.”

Then Cloudflare concluded the spectrum was the wrong shape. The 2021 hardware-key experiment and the 2022 managed challenge were two attempts to collapse it, and the second one worked by making the test adaptive instead of fixed. Once a single action could start silent and escalate only when needed, the other three actions lost most of their reasons to exist. The JS challenge became the floor you rarely want. The interactive challenge became the redundant middle. And the CAPTCHA, after September 2023, became a name pointing at machinery that no longer draws a puzzle. The taxonomy did not grow to four types by design. It accreted to four and then got hollowed back toward one.

That is the state in 2026. There are still four selectable challenge actions in the places where Cloudflare keeps backward compatibility, and there is exactly one that Cloudflare recommends and that does the interesting work. If you are reading a firewall rule and you see CAPTCHA, it is not issuing a CAPTCHA. If you see interactive, it is doing unconditionally what managed would do conditionally. If you see JS challenge, you are looking at the oldest and least adaptive gate in the set. And if you see managed, you are looking at the only one whose behaviour matches its modern documentation. The dropdown lies by omission; the clearance level is where the truth is.

---

Sources & further reading

• Cloudflare (2024), Interstitial Challenge Pages — the developer-docs definitions of the non-interactive, managed, and interactive challenge types and the recommendation to use managed.
• Cloudflare (2024), Clearance — the three clearance levels, what each bypasses, and the Turnstile pre-clearance values that map onto them.
• Tatoris, R. and Wolters, B. / Cloudflare (2022), The end of the road for Cloudflare CAPTCHAs — the managed-challenge announcement, the 91 percent reduction, the 32-seconds-to-1-second figure, and the proof-of-work and proof-of-space toolkit.
• Cloudflare (2023), Cloudflare is free of CAPTCHAs; Turnstile is free for everyone — the September 2023 GA post announcing the end of visual puzzles and the human-versus-bot CAPTCHA solving statistics.
• Prince, M. and Isasi, S. / Cloudflare (2020), Moving from reCAPTCHA to hCaptcha — the April 2020 migration, the cost and privacy reasons, and the volume of CAPTCHAs Cloudflare was serving.
• Meunier, T. / Cloudflare (2021), Humanity wastes about 500 years per day on CAPTCHAs — the Cryptographic Attestation of Personhood experiment using WebAuthn and FIDO hardware keys.
• Cloudflare (2024), Turnstile overview — the managed, non-interactive, and invisible widget modes and the relationship between Turnstile-managed and the managed challenge.
• Cloudflare (2024), JavaScript Detections — the invisible, always-on detection feature and the cf.bot_management.js_detection.passed field, distinct from the JS challenge interstitial.
• Cloudflare (2024), Cloudflare Cookies — the cf_clearance and __cf_bm cookie attributes, including SameSite=None; Secure; Partitioned and CHIPS partitioning.
• scaredos (2023), cfresearch — independent research notes on the challenge-platform request flow and the orchestration endpoints, used here for observed wire behaviour rather than documented mechanism.