hCaptcha Not Working

How hCaptcha decides to show a puzzle

hCaptcha does not show the same thing to everyone. Its FAQ says whether a visitor sees a challenge depends on its computed confidence in the visitor’s humanity, combined with the difficulty the site owner selected and other security settings. A failed answer always produces a new challenge. Paid tiers add modes that rarely or never show a puzzle, so two sites using hCaptcha can treat the same visitor very differently.

The hCaptcha privacy policy lists the kinds of data it collects to judge whether a visitor is human: mouse movements, scroll position, key presses and touch events, alongside technical data such as IP address, browser type, internet provider, device type and operating system. It does not publish how much weight any of these carry. Treat any list of “the factors hCaptcha uses” as an informed guess, including this one.

In practice, confidence drops when the session looks new every time (no cookies), when the address is shared or flagged, when input looks scripted, and when the IP changes during the visit.

Five failure types and what each points to

The hCaptcha configuration reference documents the client-side error codes a site receives. Visitors rarely see the raw code, but the behavior matches it:

• rate-limited: the user has sent too many requests.
• network-error: there are connection problems, for example the device is offline.
• script-error: the hCaptcha JavaScript could not be loaded.
• challenge-error and internal-error: setup or client failures; hCaptcha suggests the user may need to select the checkbox again.
• challenge-expired: the time limit to answer ran out.

Before changing anything on your side, check the hCaptcha status page. A reported incident explains failures across many sites at once.

Fixes in order, cheapest first

1. Reload once, then wait. Repeated refreshes add requests and can trigger rate-limited.
2. Check the status page. If hCaptcha reports an incident, nothing on your side will help.
3. Turn off extensions for the site. hCaptcha’s accessibility page says that when challenges keep returning even with its accessibility cookie set, the usual cause is an aggressive ad blocker, an anti-cookie extension or browser settings that refuse cross-site cookies, and it recommends allowing cookies for hcaptcha.com and *.hcaptcha.com. A per-site exception is better than turning protection off everywhere.
4. Allow cross-site cookies for the check. The widget runs inside a frame from hcaptcha.com, so a setting that blocks cross-site cookies can stop it remembering you. The same page gives the settings to change in Safari (cross-site tracking prevention) and Brave (shields).
5. Update the browser. According to the FAQ, official support covers each browser’s two latest major releases.
6. Look for DNS filtering. Router blocklists, filtering DNS services and some security suites block tracker-like domains. Site owners are told to allow both hcaptcha.com and its subdomains, so a filter that blocks only one subdomain can still break the widget.
7. Compare one network. Try mobile data instead of Wi-Fi, keeping the same browser. If it works, the network or its address is the cause.
8. Use the accessibility cookie if puzzles are a barrier. hCaptcha offers an accessibility sign-up that sets an encrypted cookie usable several times a day, refreshed by logging in again.

If verification fails on your own site

When visitors solve the puzzle but your form rejects them, the problem sits between your server and hCaptcha. The developer guide lists the siteverify error codes. The ones that cause most real failures:

• expired-input-response: tokens expire, 120 seconds by default. Long forms that load the widget early hit this.
• already-seen-response: a token was verified twice, often by a retry, a double submit or a second server-side check.
• sitekey-secret-mismatch: the site key and secret come from different configurations.
• missing-input-response or invalid-input-response: the token never reached your server or was altered on the way.

Send a form-encoded POST, not JSON, and include remoteip and sitekey:

curl -s https://api.hcaptcha.com/siteverify \
  -d secret="$HCAPTCHA_SECRET" \
  -d response="$TOKEN" \
  -d remoteip="$VISITOR_IP" \
  -d sitekey="$HCAPTCHA_SITEKEY"

If you use a Content Security Policy, allow https://hcaptcha.com and https://*.hcaptcha.com for scripts, frames, styles and connections. The API does not accept localhost as a hostname, so test through a hosts-file name instead, and keep the documented test keys out of production.

For proxy and automation users

A puzzle you solve is tied to the session that received it. If the exit address changes between loading the widget and submitting the form, the site sees a new session and asks again. With a rotating setup, keep one address for the whole task: rotate between tasks, not during them. On mobile proxies from Coronium the rotation timer has a 60 second minimum, and a rotation link rotates on every GET request, including link previews, so a link pasted into a chat app can change your IP in the middle of a puzzle.

Shared addresses work against you here. The IETF’s RFC 6269 explains that blocking or penalizing a shared address also hits everyone else behind it, which is why a busy carrier or VPN address can see more puzzles than a quiet one. A dedicated line removes other customers’ traffic from your address, though the address may still have history from before you used it.

For automation, assume every page script can see that the browser is automated: the W3C WebDriver standard sets navigator.webdriver to true under remote control. hCaptcha does not document whether it reads this flag. Solving services exist, and whether you may use one depends on the website’s terms, not on hCaptcha. For a broader view of the causes, read why CAPTCHAs keep appearing.

Frequently asked questions