Read this before you write any code. A CAPTCHA is an access control, and how you treat it decides whether your project is routine data collection or something a site's legal team treats very differently.

Ground rules that keep a scraping project defensible:

• Collect public data only. If a page sits behind a login you agreed not to automate, hCaptcha is not the real obstacle, the terms of service are. Do not use these techniques to get past authentication you are contractually bound by.
• Respect robots.txt and the terms of service. Many sites permit automated access to some paths and forbid others. Honor that split instead of treating every URL as fair game.
• Rate limit yourself. Slow, well-spaced requests protect the target's servers and lower your own detection risk. Hammering a login form is both rude and self-defeating, and it is the fastest way to earn a hard challenge on every request.
• Prefer an official API. If the data ships through a documented API or a data license, use it. It is cheaper, more stable, and unambiguously allowed.
• Handle personal data lawfully. GDPR, CCPA, and similar rules apply to scraped data the same as any other collection.

No method here guarantees a result, and none is a license to ignore a site's stated wishes. hCaptcha exists because a site owner asked to filter automated traffic, and defeating a challenge that guards a login or private data can raise real exposure under laws like the US Computer Fraud and Abuse Act. Public, unauthenticated data is the defensible ground. For the broader anti-detection stack that keeps you from tripping challenges in the first place, our guide on how to avoid getting your proxy blocked goes layer by layer.

hCaptcha is a CAPTCHA service from Intuition Machines, and it became the default alternative to Google reCAPTCHA when Cloudflare adopted it in April 2020. Cloudflare later built its own replacement and moved off hCaptcha to Turnstile through 2023, so any guide telling you to "bypass Cloudflare hCaptcha" is describing a setup that mostly no longer exists. Plenty of independent sites still run hCaptcha directly, which is what this guide is about.

The most expensive mistake scrapers make is assuming hCaptcha is reCAPTCHA with a different logo. It is not. The field names, the verify endpoint, and the scoring direction all differ, and code that hard-codes reCAPTCHA's details silently fails against hCaptcha.

Sign in

Here is the full lifecycle:

1. The page loads the widget (the `h-captcha` div) plus the loader script `js.hcaptcha.com/1/api.js`.
2. hCaptcha's JavaScript runs its checks and, if it is not confident, shows an image challenge ("select each image containing a bus").
3. On success it writes a token into a hidden textarea named `h-captcha-response`, and fires the optional `data-callback` with the same value.
4. When you submit the form, that token rides along in the POST body.
5. The site's backend calls hCaptcha's siteverify endpoint to check it.
6. hCaptcha replies with `success: true` or a list of error codes.

You never call siteverify yourself, but seeing what the server does makes the constraints obvious:

python

import requests

resp = requests.post(

"https://api.hcaptcha.com/siteverify",

data={

"secret": "0x_the_sites_secret_key", # server-side only, never in the page

"response": token, # the h-captcha-response value

"sitekey": "10000000-ffff-ffff-ffff-000000000001", # optional, binds the check

"remoteip": client_ip, # optional, often verified

},

timeout=10,

)

result = resp.json()

{"success": true, "challenge_ts": "2026-07-30T12:00:00Z",

"hostname": "app.sparkproxy.io", "credit": false, "error-codes": []}

if not result["success"]:

print(result["error-codes"]) # e.g. ["invalid-or-already-seen-response"]

Three properties of the token control everything you do:

- **It is single-use.** Once siteverify checks it, the token is spent. Submit the same one twice and you get `invalid-or-already-seen-response`.
- **It expires after 120 seconds.** You have a two-minute window from when the token is minted to when it must be verified.
- **It is bound to the sitekey.** If a site passes `sitekey` to siteverify, a token minted against a different sitekey fails with `sitekey-secret-mismatch`. The response also carries a `hostname`, so a token solved for the wrong domain is often worthless too.

That last point is why "just paste a token" tricks fall apart on well-configured sites. The token is not a universal key. It is a receipt tied to one sitekey, one hostname, one short window, and one use.

---

## Why Plain HTTP Clients Can Never Pass hCaptcha {#why-plain-clients-fail}

This is the insight most "bypass hCaptcha" tutorials skip, and it saves you a day of dead-end debugging. A plain HTTP client cannot produce an `h-captcha-response` token, full stop.

The token is the output of JavaScript that runs inside `js.hcaptcha.com/1/api.js`. That code renders an iframe, measures the browser environment, sometimes draws an image challenge, and only then mints the token. Tools like `requests`, `httpx`, `aiohttp`, or `curl` fetch raw HTML and never execute any of it, so there is no token to read. You can `GET` the page all day and the hidden textarea stays empty.

`curl_cffi` is worth calling out because it gets recommended for anti-bot work and people expect too much from it here. It perfectly impersonates a real browser's TLS and HTTP/2 fingerprint, which is genuinely useful for pure network-layer checks, but it still does not run JavaScript.

python

from curl_cffi import requests as cffi

This gets you a browser-grade TLS/HTTP2 fingerprint. It does NOT run the

hCaptcha challenge, so there is still no h-captcha-response to submit.

resp = cffi.get(

"https://www.sparkproxy.io",

impersonate="chrome124",

proxies={"https": "http://user:pass@gate.sparkproxy.io:7000"},

timeout=15,

)

The rule is blunt: hCaptcha is a JavaScript problem first and a fingerprint problem second. No JS runtime, no token. Every working approach below therefore uses a real browser engine or a rendering service that runs one for you.

---

## hCaptcha Enterprise: the Risk Score Runs Backwards {#enterprise-score}

hCaptcha Enterprise (the paid tier, once marketed as BotStop) adds a passive mode that can score a visitor with no visible challenge at all, plus two fields on the siteverify response that the free tier omits: `score` and `score_reason`.

Here is the part that catches everyone migrating from reCAPTCHA. In reCAPTCHA v3, a higher score means more human, and 0.5 is a common pass threshold. In hCaptcha Enterprise, the `score` is a **risk** score: higher means more bot-like. A `score` near 0.0 is a clean visitor, and a `score` near 1.0 or above is almost certainly automation. If you copy a reCAPTCHA threshold check straight across, you invert your own logic and either block everyone or nobody.

python

hCaptcha Enterprise adds these two fields to the siteverify response.

score is a RISK value: HIGHER means more bot-like, the inverse of reCAPTCHA v3.

result = resp.json()

if result.get("success"):

risk = result.get("score", 0.0) # 0.0 clean ... 1.0+ automated

reasons = result.get("score_reason", []) # e.g. ["automation", "fraud_prevention"]

if risk >= 0.7:

print("high-risk token, the site will likely reject it", reasons)

Enterprise also introduces `rqdata`, a signed blob the widget is initialized with. When a site uses it, a valid token must be produced against that exact `rqdata`, which matters a lot for solver services (covered below). The practical takeaway for prevention is the same as everywhere else: since Enterprise passive mode is scoring your client without showing a puzzle, a flagged datacenter IP or a headless fingerprint fails you silently, with no grid to even attempt.

---

## The Accessibility Cookie, and Why It Is Not Your Shortcut {#accessibility-cookie}

For years, the top "bypass hCaptcha" trick was the accessibility cookie, and you will still find guides pushing it. Here is the honest status so you do not waste time on it.

hCaptcha ran an accessibility program at `accessibility.hcaptcha.com` for users who could not solve visual challenges. You signed up with an email, clicked a link, and your browser received a cookie that let you pass hCaptcha widgets without solving them for a set window. Scrapers seized on it: grab the cookie once, replay it on every request, skip the challenge entirely. It worked well enough that it became the default advice.

That door is effectively closed. hCaptcha deprecated the old cookie-based flow after widespread automated abuse and moved toward a Privacy Pass model, where a browser extension issues cryptographic tokens after you legitimately solve challenges, redeemable to skip future ones. Two things follow. First, any code or tutorial that tells you to fetch a bypass cookie from `accessibility.hcaptcha.com` is stale, and the endpoint behavior it assumes is gone. Second, the accessibility program exists for people with disabilities, and scripting against it is exactly the abuse that got the cookie flow locked down. Do not build on it. Privacy Pass tokens are also per-browser and earned by solving, so they are not a scraping shortcut either.

If a stale guide sent you here expecting a cookie trick, the durable answer is the same one that works everywhere: lower your risk score so the challenge stops firing, and solve only when a site deliberately gates a public action.

---

## Detect hCaptcha and Grab the Sitekey {#detect}

Before you build browser automation, confirm the page actually uses hCaptcha and pull its sitekey. A plain HTTP fetch of the raw HTML is enough for detection, even though it can never solve the widget. Treat a `200 OK` that contains an hCaptcha widget as a soft block, not a success, so check the body, not just the status code.

python

import re

import requests

def analyze_hcaptcha(url: str) -> dict:

"""Detect hCaptcha and extract the sitekey. Detection only, cannot solve."""

html = requests.get(url, timeout=15).text

markers = [

"js.hcaptcha.com/1/api.js",

'class="h-captcha"',

"h-captcha-response",

]

present = any(m in html for m in markers)

sitekey = None

match = re.search(r'data-sitekey="\'["\']', html)

if match:

sitekey = match.group(1)

return {"hcaptcha": present, "sitekey": sitekey}

print(analyze_hcaptcha("https://app.sparkproxy.io/login"))

{'hcaptcha': True, 'sitekey': '10000000-ffff-ffff-ffff-000000000001'}

hCaptcha publishes test credentials you can develop against without touching a real site: sitekey `10000000-ffff-ffff-ffff-000000000001` paired with the secret `0x0000000000000000000000000000000000000000` always passes. Use them to exercise your token-reading and siteverify handling before you point anything at production. The sitekey you extract is the public identifier a solver service needs, so pulling it reliably is step zero for both the browser route and the solver route below.

---

## Prevention: Pass Without Solving {#prevention}

This is where most hCaptcha problems are actually won. When your client looks like an ordinary visitor, hCaptcha either shows a one-click checkbox that auto-resolves or, in Enterprise passive mode, never challenges at all. Solving is what you do when prevention fails, and it should be the exception. With no Google-session lever to pull, three things move your risk score.

**1. Clean residential exit IPs.** IP reputation is the single biggest input, and it is the one you can change instantly. Datacenter subnets are pre-classified and already burned by other scrapers, so you start near the floor and draw a hard image grid on every request. Residential IPs carry the reputation of ordinary home connections and clear the first gate far more often. If you are new to the category, [what is a residential proxy](/blog/what-is-a-residential-proxy-types-use-cases-2026) explains the types and sourcing.

**2. A real, consistent browser fingerprint.** hCaptcha probes for the usual automation tells:

- `navigator.webdriver` should read `false`, not `true`.
- `HeadlessChrome` must not appear anywhere in the User-Agent.
- The UA must match the real browser version and platform, and match the TLS and HTTP/2 fingerprint the same client presents.
- WebGL, canvas, timezone, and locale should be internally consistent, not a headless default paired with a US locale on a German IP.

Drive a real Chromium through Playwright or a hardened automation stack, not a stripped headless binary.

**3. Trust built over time.** Accept and reuse cookies, keep a stable session per IP, and space requests with human-like timing. A brand-new client with an empty cookie jar hitting a login form ten times a second is the exact pattern hCaptcha is tuned to escalate. Land on a neutral page first, let the session accumulate a little history, and rotate the whole bundle of profile, IP, and fingerprint together rather than shuffling one piece at a time.

Get these three right and most hCaptcha widgets simply resolve. For the general version of this playbook across every CAPTCHA vendor, see [how to avoid CAPTCHAs when web scraping](/blog/how-to-avoid-captchas-when-web-scraping).

---

## Read the Token in a Real Browser {#read-token}

When a page needs the widget to run, drive a real browser, let hCaptcha resolve, and read the token out of the hidden textarea. Playwright with a non-headless Chromium routed through a residential exit is the cleanest way to do it.

python

from playwright.sync_api import sync_playwright

def get_hcaptcha_token(url: str, timeout_ms: int = 30000) -> str | None:

with sync_playwright() as p:

browser = p.chromium.launch(headless=False) # headful passes more often

context = browser.new_context(

proxy={

"server": "http://gate.sparkproxy.io:7000",

"username": "YOUR_PROXY_USER",

"password": "YOUR_PROXY_PASS",

},

locale="en-US",

timezone_id="America/New_York",

)

page = context.new_page()

page.goto(url, wait_until="domcontentloaded")

hCaptcha writes its token into a hidden textarea named

h-captcha-response once the challenge resolves.

try:

page.wait_for_function(

"""() => {

const el = document.querySelector('[name="h-captcha-response"]');

return el && el.value && el.value.length > 20;

}""",

timeout=timeout_ms,

)

except Exception:

browser.close()

return None # widget never resolved: IP or fingerprint flagged

token = page.eval_on_selector(

'[name="h-captcha-response"]', "el => el.value"

)

browser.close()

return token, context

print(get_hcaptcha_token("https://app.sparkproxy.io/login"))

The pattern is deliberate. You do not "click" or "solve" anything by hand. You load the page with a clean fingerprint and a good IP, then wait for the token hCaptcha mints on its own. If `wait_for_function` times out, that is prevention failing, and the fix is a better IP or fingerprint, not a longer timeout.

Once you have the token, submit it with the rest of the form within the 120-second window. Reuse the browser's cookies so the request looks like it came from the same session that resolved the widget:

python

import requests

cookies = {c["name"]: c["value"] for c in context.cookies()}

resp = requests.post(

"https://app.sparkproxy.io/login",

data={

"email": "you@sparkproxy.io",

"password": "your_password",

"h-captcha-response": token, # single-use, submit once within 120s

},

cookies=cookies,

timeout=15,

)

print(resp.status_code)

Mint a fresh token for each submission. The moment siteverify checks one, it is dead.

---

## Last Resort: hCaptcha Solver Services {#solvers}

Here is where hCaptcha differs from Turnstile and reCAPTCHA v3 in your favor. Because hCaptcha's core is still a genuinely solvable image challenge, solver services have something concrete to do: run a browser farm, classify the images, and return a token. That makes solvers more viable for hCaptcha than for the invisible score-only systems, where a purchased token often carries a losing score anyway. Treat it as a paid fallback, not a first move, and know that using one may breach the target's terms of service.

The flow is always the same. Send the service the page URL and sitekey, poll for a token, then submit that token yourself.

python

Illustrative solver flow. Swap in your provider's real endpoints.

import time

import requests

def solve_hcaptcha(site_url: str, sitekey: str, rqdata: str = "") -> str | None:

create = requests.post("https://api.your-solver.example/createTask", json={

"clientKey": "YOUR_SOLVER_KEY",

"task": {

"type": "HCaptchaTaskProxyless",

"websiteURL": site_url,

"websiteKey": sitekey,

"isEnterprise": bool(rqdata), # Enterprise flag

"enterprisePayload": {"rqdata": rqdata} if rqdata else {},

},

}, timeout=20).json()

task_id = create.get("taskId")

for _ in range(30):

time.sleep(3)

res = requests.post(

"https://api.your-solver.example/getTaskResult",

json={"clientKey": "YOUR_SOLVER_KEY", "taskId": task_id},

timeout=20,

).json()

if res.get("status") == "ready":

Solvers return the token under gRecaptchaResponse for compatibility;

it is the h-captcha-response value you inject below.

return res["solution"]["gRecaptchaResponse"]

return None

The token is worthless until you place it where the site reads it, which for hCaptcha is the hidden `h-captcha-response` textarea:

python

token = solve_hcaptcha("https://app.sparkproxy.io/protected", sitekey)

page.evaluate(

"(t) => { document.querySelector('[name=\"h-captcha-response\"]').value = t; }",

token,

)

page.click("button[type=submit]") # trigger the real form submission

Before you lean on solvers, know their limits.

| Limitation | Why it bites |
|---|---|
| Token bound to sitekey and hostname | A token solved for the wrong sitekey fails with `sitekey-secret-mismatch` |
| 120-second TTL | Solving takes 10 to 60 seconds, so a slow submit returns `invalid-or-already-seen-response` |
| Single use | You cannot batch one token across many submissions |
| Enterprise `rqdata` | If the widget sets `rqdata` and the solver does not receive it, the token fails |
| IP mismatch | If the site passes `remoteip` to siteverify, a token minted on the farm's IP may be rejected |
| Cost and latency | Every solve is a paid request that adds seconds to your pipeline |

If per-solve fees stack up at volume, building your own classifier becomes the cheaper path. We walk through that end to end in [how to build a CAPTCHA solver with machine learning](/blog/how-to-build-a-captcha-solver-with-machine-learning). It is a real project with real tradeoffs, so treat it as the destination, not the first stop.

---

## Let the SparkProxy Scraping API Handle It {#scraping-api}

Running and hardening your own browser fleet is ongoing engineering: patched Chromium, fingerprint management, a residential pool, and retry logic for every widget that escalates. The SparkProxy Scraping API folds all of that into one request. It renders the page in a real headless Chromium, so the hCaptcha JavaScript actually executes, routes through clean residential exits, and applies a consistent fingerprint.

Three parameters matter for hCaptcha pages. `render_js=true` executes the widget's challenge script, which is the non-negotiable requirement for producing a token. `premium_proxy=true` routes through the residential tier so your IP reputation is clean. `stealth=true` adds the fingerprint consistency layers that keep the risk score down.

bash

curl -G "https://scrape.sparkproxy.io/api/v1" \

-H "X-API-Key: YOUR_API_KEY" \

--data-urlencode "url=https://app.sparkproxy.io/pricing" \

--data-urlencode "render_js=true" \

--data-urlencode "premium_proxy=true" \

--data-urlencode "stealth=true" \

--data-urlencode "country_code=US" \

--data-urlencode "wait_for=.h-captcha"

The same call in Python, asking for a JSON envelope so you can read the metadata and react when a challenge fires:

python

import requests

r = requests.get(

"https://scrape.sparkproxy.io/api/v1",

headers={"X-API-Key": "YOUR_API_KEY"},

params={

"url": "https://app.sparkproxy.io/pricing",

"render_js": "true", # execute the hCaptcha challenge JS

"premium_proxy": "true", # clean residential exit IP

"stealth": "true", # consistent browser fingerprint

"country_code": "US",

"wait_for": ".h-captcha", # let the widget mount

"json_response": "true", # wrap body + metadata

},

timeout=120,

)

data = r.json()

if data.get("captcha_type") == "hcaptcha":

rotate to a fresh residential exit and retry before reaching for a solver

print("hCaptcha fired, rotating exit and retrying")

```

On a CAPTCHA failure the response carries a captcha_type field set to hcaptcha, recaptcha, cloudflare_turnstile, or null for a purely behavioral block, so you react instead of guessing. For scraping content behind an hCaptcha-protected public page, this is usually the shorter path: send a URL, get back rendered HTML, and let the IP quality and fingerprint work happen server-side. If you are weighing whether to build this or buy it, our comparison of a web scraping API versus self-managed proxies lays out the real cost math on both sides.

Most of these trace back to one of two root causes: no JavaScript runtime, or a bad risk score. Fix the runtime with a real browser or render_js=true, fix the score with a clean IP and a consistent fingerprint, and the error list shrinks fast.