Every CAPTCHA Type, and What Solving Each One Means

"Solve the CAPTCHA" sounds like one operation. It isn't. Depending on which challenge you hit, a successful solve hands back one of three completely different artifacts: a string of text, a verification token, or a clearance cookie plus the user agent that earned it. Those three go to three different places in your code, have three different lifetimes, and fail for three different reasons. Most broken solver integrations aren't broken solvers — they're a token pasted where a cookie belongs, or a cookie reused with the wrong user agent.

The key takeaway: classify every challenge by what it returns, not by what it looks like. Text answers go into a form field in the same session that fetched the image. Tokens go into a hidden input or the page's JS callback and expire in minutes. Clearance cookies go into your cookie jar, bound to your user agent and usually your exit IP. Get the artifact right and the rest is plumbing.

The three output classes

Every number in that table is CaptchaAI's own published figure for its service, not an independent benchmark. Treat them as the vendor states them.

Text-answer challenges: image, grid, and numeric grids

Classic image CAPTCHAs

The server renders a distorted string, keeps the expected answer in the session, and shows you the picture. Solving is optical: read the glyphs, return the string. Nothing cryptographic is happening.

The integration trap is session binding. The expected answer lives in the session that served the image. Fetch the image with one HTTP client and post the form with another — a common accident when a solver helper does its own request — and the answer is correct while the submission still fails. Fetch the bytes inside the same cookie jar you'll post from, and send those bytes (base64) to the solver rather than the image URL.

CaptchaAI publishes >99% success in under 0.5 seconds across a stated 27,500+ image variants here — the fastest category, precisely because there's no browser state to reproduce.

Grid image CAPTCHAs

"Select all squares containing a bus." Mechanically still a text answer — the wire format is a set of tile indices — but it's a classification problem rather than character recognition, and grids often refresh after a correct selection to demand a second round. Budget for multi-round interaction, not a single call. Published: >99% in under a second.

BLS-style numeric grids

Appointment and government-services portals often serve a variant where a number is displayed and you click the tiles carrying it. Same output class, and CaptchaAI publishes >99% in under a second here too.

Worth stating plainly: portals of this kind almost always prohibit automated interaction in their terms, and many are queue systems where automation directly disadvantages other users. Read the terms first. The legitimate reasons to handle this class are accessibility testing and QA of a portal you own or are contracted to test.

Token challenges: reCAPTCHA and Turnstile

Here the mechanism changes completely. The widget runs in the page, gathers behavioural and environment signals, and — if satisfied — produces an opaque response token. Your form carries that token; the site's backend then calls the provider's verification endpoint to check it. You aren't defeating a puzzle, you're obtaining a token the origin will accept when it verifies.

Two consequences fall straight out of that. Tokens are single-use and short-lived — reCAPTCHA responses expire on the order of a couple of minutes, so a token solved during a queue backlog is already wasted. Solve late, immediately before the submit that consumes it, rather than pre-warming a pool. And tokens are bound to the site key and page URL they were minted for; the same key on a different path can be rejected.

reCAPTCHA v2, invisible, and Enterprise

v2 checkbox is the familiar "I'm not a robot" box, which may or may not escalate into an image grid. v2 invisible has no box: it binds to your submit button and fires a JS callback. v2 Enterprise speaks the same protocol shape on Google's enterprise scoring backend, giving the site richer risk signals.

For all three the artifact is identical and lands in the same place — the g-recaptcha-response field, or whatever callback the page registered. CaptchaAI publishes >99.5% in under 60 seconds for v2 checkbox and v2 Enterprise, and >99% in under 30 seconds for v2 invisible.

reCAPTCHA v3 and v3 Enterprise

v3 shows the user nothing; there's no puzzle to pass. It scores the session from 0.0 to 1.0 and hands the page a token carrying that score plus an action name (login, search, checkout — whatever the site declared).

That action string is what people get wrong. Supply a token minted for a different action than the page requested and verification fails at the origin even though the token is genuine and unexpired. Read the action out of the page's JS before you solve.

The second thing to internalise: the site chooses the score threshold. A v3 token is an assessment, not a pass — any solver can return a well-formed, correctly-actioned token and the origin can still reject the request. CaptchaAI publishes >99% in under 4 seconds for v3 and v3 Enterprise; that describes producing the token, which is the only part a solver controls.

Cloudflare Turnstile

Turnstile is Cloudflare's drop-in alternative to reCAPTCHA: a widget in a form producing a token in cf-turnstile-response, verified server-side. Treat it architecturally like a reCAPTCHA v2 token — same lifecycle, same "solve late" rule. CaptchaAI publishes 100% success in under 10 seconds.

The odd one out: Cloudflare Challenge

This is where integrations most often go sideways: the name sits next to Turnstile and the behaviour is nothing like it.

A Cloudflare Challenge (the interstitial "Checking your browser…" / managed challenge) doesn't guard a form. It guards the page itself — the HTML never arrives until you clear it, and there's no field to fill. Clearing it produces a cf_clearance cookie, valid only alongside the exact user agent that earned it and, in practice, the same exit IP.

So the flow inverts. Token types need one solve per submit, discarded immediately. Clearance needs one solve per session, then gets reused across every subsequent request in it. Three rules follow: solve through the same proxy you'll browse with — hence the per-task proxy and proxytype parameters CaptchaAI exposes; set your client's user agent to the one returned with the cookie, exactly; and keep the cookie, because one clearance can cover hundreds of page fetches.

Why a site turns any of this on in the first place — fingerprinting, ASN reputation, TLS signals, behavioural scoring — is a separate mechanism worth understanding before you tune anything; see how anti-bot detection works.

Geetest v3: three fields, not one

Geetest v3 is the slider/puzzle family. Its handshake starts from a gt and a challenge value the page fetches from Geetest's API, and a successful solve returns three values: a new challenge, a validate and a seccode. All three go into the site's verification request.

This is the concrete reason "just give me the token" abstractions break — a wrapper that models a solve as one string cannot express Geetest. Model your solver result as a structured object from day one. CaptchaAI publishes 100% success in under 12 seconds here.

What this looks like at the API

CaptchaAI uses the legacy 2Captcha-shaped protocol on ocr.captchaai.com: submit to /in.php, poll /res.php. Add json=1 for structured responses; omit it for legacy plain text. The API key is 32 characters. Submitting an image CAPTCHA, base64, fetched in the session you'll post from:

curl -s https://ocr.captchaai.com/in.php \
  -F "key=YOUR_API_KEY" \
  -F "method=base64" \
  -F "json=1" \
  -F "body=$(base64 -w0 captcha.png)"

Then poll roughly every 5 seconds until it stops answering CAPCHA_NOT_READY:

curl -s "https://ocr.captchaai.com/res.php?key=YOUR_API_KEY&action=get&id=2122988149&json=1"
# {"status":0,"request":"CAPCHA_NOT_READY"}
# {"status":1,"request":"h8y3xk"}      <- the text answer

The submit parameters differ per type — a token type needs the site key and page URL, a v3 needs the action, a Geetest needs gt and challenge, a clearance type needs the proxy you'll browse from. Check the per-type parameter list in the docs; the shape is identical, the fields are not.

What's worth wiring once, generically:

• Poll cadence ~5s. Hammering /res.php gains nothing.
• Three error codes to branch on. CAPCHA_NOT_READY means keep waiting. ERROR_UNSOLVABLE means retry the challenge — fetch a fresh one, don't re-poll the dead task ID. ERROR_ZERO_BALANCE means stop and alert; retrying is noise.
• Webhooks instead of polling where your architecture allows, plus bulk submission when solving many at once.
• Per-task proxy/proxytype — mandatory for clearance work, usually unnecessary for tokens.

Examples ship for cURL, Python, Node.js, PHP, Go, Java, .NET, Ruby, Rust and Postman, and a compatibility emulator mimics other services by host swap — the shortest path if you already have working code against another provider's legacy endpoint.

Why the artifact type also decides your bill

CaptchaAI prices concurrent threads, not solves: unlimited solves per thread, no per-CAPTCHA fee, no daily cap, and no surcharge for harder types. Published entry points are BASIC at $15/month for 5 threads, ADVANCE at $90/month for 50 threads (from about $0.09 per 1K) and ENTERPRISE at $300/month for 200 threads (from about $0.030 per 1K), on a ladder running BASIC, STANDARD, ADVANCE, PREMIUM, CORPORATE, ENTERPRISE and VIP-1/2/3.

So the sizing question is how many solves are in flight at once, and that follows from the artifact. Token sites need one solve per submitted form: threads track your submit rate. Clearance sites need one per session: threads track session churn, often orders of magnitude lower than request rate. And slow types dominate — something published at under 60 seconds holds a thread far longer than something under a second, so size on your slowest type.

Staying on the right side of this

CAPTCHA handling belongs in QA automation for flows you own, accessibility testing, uptime and content monitoring, and lawful data collection. It does not belong near authentication bypass, account creation at scale, payment flows or credential testing. Read robots.txt, honour published rate limits, and if a site's terms forbid automated access, that answer stands regardless of which challenge it serves.

FAQ

Does a valid reCAPTCHA v3 token guarantee the site accepts my request? No. v3 returns a score and the origin picks the threshold. A correctly-actioned, unexpired token can still be rejected. Any published success rate for v3 describes producing the token; the acceptance decision is the site's.

What's the actual difference between Cloudflare Turnstile and a Cloudflare Challenge? Turnstile is a form widget yielding a token for cf-turnstile-response. A Challenge gates the page itself and yields a cf_clearance cookie plus a user agent. Token into a field; cookie into your jar, with the matching UA and the same exit IP.

Do I need a proxy to solve? For clearance-cookie challenges, yes — the cookie is tied to the IP and user agent that earned it, so the solve must go through the proxy you'll browse with. For token types it's usually unnecessary.

Why does my token verify in isolation but fail in the real flow? Usually one of three things: the action name doesn't match what the page requested (v3), the token expired while queued, or it was minted for a different site key or page URL.

Do harder CAPTCHA types cost more? Not under thread-based pricing — you buy concurrency, with unlimited solves per thread and no per-type surcharge. Harder types cost you latency, which shows up as threads held open longer.

Once you stop thinking in "CAPTCHA types" and start thinking in text, token, cookie, most of the guesswork disappears: you know where the result goes, how long it lives, whether it needs a proxy, and how many threads it will hold open. If you're wiring that up, the CaptchaAI docs and thread tiers are a quick way to test that against your own traffic — start with the type actually blocking you and size from what you measure.