hCaptcha vs reCAPTCHA: differences, tokens, and solving.

hCaptcha and reCAPTCHA are two competing captcha services that both hand the browser a short-lived, single-use token your backend verifies. They come from different vendors, use different token fields, and split into different modes (checkbox, invisible, and score-based). Here’s how they actually differ.

What each one is

hCaptcha is built by Intuition Machines and is the captcha you’ll most often meet behind Cloudflare-fronted sites and privacy-focused properties. The classic flavour shows an image-grid challenge; it also ships an invisible mode and an enterprise mode that binds each challenge to a fresh rqdata blob and the visitor’s session.

reCAPTCHA is Google’s captcha. v2 is the familiar “I’m not a robot” checkbox (with an optional invisible variant) that may pop an image challenge. v3 works differently: it runs silently and never interrupts the user, returning a risk score your server acts on.

hCaptcha vs reCAPTCHA at a glance

Token mechanics: the part that trips people up

Both services follow the same shape: the widget runs on the page, the user (or an invisible check) passes, and the captcha injects a token into a hidden field that rides along with the form post. Your backend then calls the vendor’s siteverify endpoint to confirm it. The fields are not interchangeable:

<div class="h-captcha" data-sitekey="f5ab1c2d-..."></div>

<!-- after a solve, hCaptcha injects: -->
<textarea name="h-captcha-response">P1_eyJ0eXAi...UV8w</textarea>

<div class="g-recaptcha" data-sitekey="6Lc...ABC"></div>

<!-- after a solve, reCAPTCHA injects: -->
<textarea name="g-recaptcha-response">03AGdBq2...9fH</textarea>

A few properties matter if you’re automating this. Validity is short: both tokens default to roughly 120 seconds. hCaptcha returns expired-input-response past that window, and reCAPTCHA tokens likewise expire two minutes after issue. Both are also single-use. Resubmit one and you get already-seen-response (hCaptcha) or a duplicate-token failure (reCAPTCHA). And a token is effectively bound to the sitekey it was minted for: hCaptcha lets you enforce that by passing the sitekey to siteverify, and reCAPTCHA ties the token to the key pair you verify with. You cannot mint a token on an easy key and redeem it on a hard one.

Checkbox vs score vs invisible

The biggest conceptual gap is between a challenge model and a score model.

• reCAPTCHA v2 checkbox and hCaptcha (regular) are challenge-first: they may show an image grid and produce a pass/fail token. Your backend just checks success: true.
• Invisible modes (hCaptcha invisible, reCAPTCHA v2 invisible) still issue a pass/fail token but try to clear most visitors without a visible challenge, only escalating to a grid when risk looks high.
• reCAPTCHA v3 drops the challenge entirely. It returns a 0.0 to 1.0 score (1.0 likely human, 0.0 likely bot) plus an action name, and hands the allow/block decision to you. hCaptcha’s nearest equivalent is its enterprise bot-score mode.

Detection and difficulty

Because v3 is purely behavioural, there’s no grid to “solve.” The hard part is producing a request that scores like a human across reputation, history, and execution signals. hCaptcha enterprise leans the other way: each session carries an IP- and session-bound rqdata payload, so a token has to be minted in a real browser context that matches the challenge rather than image-recognised in isolation. Both raise the bar versus a plain checkbox, just in different places. v3 leans on behavioural reputation, enterprise hCaptcha on session-bound challenge data.

How programmatic solving differs

For a challenge-style captcha (hCaptcha regular/invisible, reCAPTCHA v2), a solver’s job is concrete: produce a valid token and you submit it as the matching *-response field. For score-style reCAPTCHA v3 there is no token to “win.” Passing depends on the whole request looking trustworthy, which is a harder, fuzzier target.

NoneCap is a hosted hCaptcha solver. You POST a sitekey and url, optionally block for the result with ?wait=N, and read back a real P1_ token that you submit as the page’s h-captcha-response:

curl "https://api.nonecap.com/v1/solves?wait=90" \
  -H "Authorization: Bearer $NONECAP_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type":    "hcaptcha",
    "sitekey": "f5ab1c2d-7e8f-4a9b-b1c2-d3e4f5a6b7c8",
    "url":     "https://target.example/login"
  }'

{
  "id":              "solve_01HQF7K3JKWZX",
  "object":          "solve",
  "type":            "hcaptcha",
  "status":          "solved",
  "token":           "P1_eyJ0eXAi...UV8w",
  "credits_charged": 1
}

NoneCap returns tokens that enterprise (rqdata) sitekeys accept, not just image-recognition output. See the API reference for the full solve object, the enterprise fields, and every language sample.

Which solver covers which

To be clear about scope: NoneCap solves hCaptcha only, covering regular, invisible, and enterprise rqdata. It does not solve reCAPTCHA v2 or v3, Cloudflare Turnstile, or FunCaptcha today; those are on the roadmap, not shipped. If your target uses reCAPTCHA, NoneCap won’t help yet. If it’s hCaptcha, including the enterprise variant that breaks image-only solvers, that’s exactly what NoneCap is built for.