The hCaptcha accessibility cookie, and what happened to it.

For a few years the fastest way past hCaptcha was not solving it. You signed up for an accessibility account, got a cookie, and the widget waved you through. Every scraping thread linked it. That path is effectively closed now, and this page explains what the cookie was, why it stopped working for automation, and what hCaptcha actually offers accessibility users today.

What the accessibility cookie was

hCaptcha runs a genuine accessibility program for people who cannot solve image puzzles. You sign up on a dedicated page, confirm an email, and hCaptcha issues an encrypted cookie scoped to hcaptcha.com. When a widget loads, it reads that cookie and decides what to show you. In the program's early form the decision was simple: a valid cookie passed the challenge outright, no clicking required.

That early behaviour is the whole reason the cookie ended up in automation guides. It was a free, persistent token that skipped challenges, and the signup that minted it asked only for an email. So scripts started using it. Researchers went further and showed the entire enrollment could be driven by a bot: point a controlled domain's mail server at the confirmation email, rotate IPs, and you could mint accessibility cookies in bulk. One public write-up put the cost per bypass, amortised across reuse, at close to zero. From roughly 2020 to 2022 the accessibility cookie was the cheapest hCaptcha bypass going, which is exactly why it could not last.

Why it stopped working for automation

hCaptcha did not delete the program. It tightened every part of it that made the bot abuse cheap, and those same changes are what break the cookie as a scripted bypass. Four things changed.

The pass became conditional. A valid cookie no longer guarantees a skip. hCaptcha's own description is that accessibility users "automatically pass or receive an accessibility challenge, depending on the site's settings and other factors." So even a clean, legitimately issued cookie can still hand you a challenge to solve, which is the opposite of what a bypass needs.

Enrollment got expensive. Signup is no longer an email and a click. Current accounts require a one-time code you confirm by SMS to a US phone number, which kills the bulk-minting trick that depended on a throwaway mail domain. The cookie is also rate limited to a few uses per day, has to be refreshed by logging back in, and expires in about 24 hours.

Browsers stopped carrying it. The cookie is set on hcaptcha.com and read inside a cross-site iframe, so it is a third-party cookie. Safari and Firefox block those by default, and Chrome has been deprecating them, so in a normal modern browser the cookie often is not sent at all and the widget behaves as if you never enrolled.

Enterprise ignores it. Custom-domain and enterprise sitekeys, the ones that pass a fresh rqdata blob per challenge, do not honour the hcaptcha.com accessibility cookie. The higher-value targets a scraper actually cares about were never in scope.

What hCaptcha offers accessibility users today

The program is real, and it is worth getting right, because this is an accommodation for disabled users and not a loophole. hCaptcha gives accessibility users two paths. The first is the account and cookie above: enroll once, and enabled sites either let you through or give you an easier challenge. The second is an in-widget Accessibility Challenge, a text or language-agnostic alternative to the image grid that a site owner can switch on. hCaptcha is also bringing Privacy Pass into the accessibility flow as the longer-term replacement for the cross-site cookie.

Disabled users report that both paths are patchy in practice. The text challenge only shows up if the individual site enabled it, and most never do, so the "accessible" fallback is often just the image puzzle again. The cookie depends on third-party cookies that the user's own browser blocks. The accommodation exists and hCaptcha keeps investing in it, but coverage is inconsistent enough that critics have called it accessibility theatre. None of that turns it into a bypass you can lean on.

The honest conclusion for automation

There is no cookie you can grab that skips hCaptcha challenges at scale anymore. The signup is gated behind an SMS step, the pass is conditional and risk-graded, the cookie is rate limited and blocked as a third-party cookie in modern browsers, and enterprise sitekeys never honoured it. On top of that, the program exists for people who need it, and automating an accommodation built for disabled users is the abuse hCaptcha shut the door on. Chasing the cookie in 2026 means fighting all of that for a token that might still make you solve a challenge.

The path that works is the direct one: solve the challenge and submit a real token. Send the sitekey and page url to /v1/solves, block for the result with ?wait=N, and read back a P1_ token.

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
}

Submit that token as the form's h-captcha-response and the page treats it as a real pass. Billing starts at one credit per challenge round, charged only when the solve succeeds, and the token works on regular, invisible and enterprise sitekeys rather than depending on a site having an accessibility option enabled. The full solve object and every language sample are in the API reference, and the token guide covers what h-captcha-response is and how long it stays valid.