reCAPTCHA Solver Token Invalid — Diagnosis and Fixes

When Google's siteverify endpoint returns "invalid-input-response", the reCAPTCHA token has been rejected. The token was generated by the solver but is not being accepted by the site. This article covers every known cause and the corresponding fix.

For a broader troubleshooting overview, see the CAPTCHA Solver Troubleshooting Guide.

Response Types and What They Mean

Google's reCAPTCHA verify endpoint returns one of these error codes:

The most common from automated pipelines: invalid-input-response and timeout-or-duplicate.

Cause 1 — Token Expired

reCAPTCHA tokens expire after 2 minutes from issuance. This is the most frequent cause of timeout-or-duplicate.

Fix: Solve immediately before submitting:

# Solve at the last moment — don't cache tokens
token = solve_recaptcha_v2(api_key, page_url, site_key)
# Submit within seconds of receiving the token
response = submit_form(token)

Never pre-solve tokens in a queue. Never re-use a token from a previous session.

Cause 2 — Token Injected into Wrong Field

Sites that use reCAPTCHA v2 expect the token in a field named exactly g-recaptcha-response. Some frameworks use a textarea with this name inside the widget <div>. If you inject into the wrong element (e.g., the <div> itself or a similarly-named custom field), the form POSTs without the token.

Fix: Target the correct field precisely:

page.evaluate(f"""
    // Target ALL elements named g-recaptcha-response (there may be more than one)
    document.querySelectorAll('[name="g-recaptcha-response"]').forEach(el => {{
        el.value = '{token}';
    }});
""")

After injection, verify the value is set before clicking submit:

injected = page.eval_on_selector('[name="g-recaptcha-response"]', 'el => el.value')
assert injected == token, "Token injection failed"

Cause 3 — Wrong Endpoint (Enterprise vs Standard)

reCAPTCHA Enterprise tokens are generated against google.com/recaptcha/enterprise.js. Standard tokens are generated against google.com/recaptcha/api.js. They are not interchangeable. Submitting a standard token to an Enterprise-protected site returns invalid-input-response.

How to detect: Inspect the page source and look for which script is loaded.

import re, requests

def detect_recaptcha_type(page_url: str) -> str:
    html = requests.get(page_url, headers={"User-Agent": "Mozilla/5.0"}, timeout=15).text
    if "recaptcha/enterprise.js" in html or "/recaptcha/enterprise" in html:
        return "enterprise"
    return "standard"

Fix: Pass enterprise=1 to the solver when Enterprise is detected:

payload = {
    "key": api_key,
    "method": "userrecaptcha",
    "version": "v3",       # Enterprise is always v3-based
    "enterprise": 1,       # ← Required for Enterprise endpoint
    "googlekey": site_key,
    "pageurl": page_url,
    "json": 1,
}

Cause 4 — reCAPTCHA v3 Score Too Low (Silently Blocked)

v3 failures don't always return invalid-input-response. Sites using v3 may silently block a low-scoring token by returning a "suspicious activity" message or a generic 403. The CAPTCHA API itself confirms the token is valid — the score just doesn't meet the site's threshold.

Diagnosis: Check if the site is using v3 (no visible checkbox). If silently blocked, the token validated but was acted on adversely.

Fix: Request a minimum score:

payload = {
    "method": "userrecaptcha",
    "version": "v3",
    "min_score": 0.7,      # Ask solver for a 0.7+ scored token
    "action": "login",     # Match the site's action name
    ...
}

See How to Solve reCAPTCHA v3 in Python for the full v3 pattern.

Cause 5 — Action Name Mismatch (v3 and Enterprise)

v3 and Enterprise tokens bind the action name at generation time. If the site validates the action server-side and your solver generates a token with action: verify when the site expects action: login, the token fails.

Fix: Extract the action name from the page JS and pass it to the solver:

import re

action_m = re.search(r'action\s*:\s*["\']([a-zA-Z0-9_/]+)["\']', html)
action = action_m.group(1) if action_m else "verify"

Cause 6 — Site Key from Wrong Environment

Using a staging/sandbox site key with a production solver URL generates tokens that are cryptographically valid but registered to the wrong site key in Google's system.

Fix: Extract the site key from the live production URL, not from source code or docs.

Cause 7 — Page URL Mismatch

The pageurl parameter sent to the solver must match the actual URL where reCAPTCHA is embedded. Tokens generated for https://example.com/login will fail when submitted to https://example.com/login?ref=promo if the site performs strict origin checking.

Fix: Use the exact canonical URL of the page with the CAPTCHA widget.

Quick Diagnostic Checklist

1. ✅ Token generated within the last 2 minutes?
2. ✅ Injecting into [name="g-recaptcha-response"]?
3. ✅ Site uses standard reCAPTCHA (not Enterprise)?
4. ✅ If Enterprise, passing enterprise=1 to solver?
5. ✅ If v3, passing correct action and min_score?
6. ✅ Site key extracted from the live page URL?
7. ✅ pageurl in solver request matches the live CAPTCHA page URL?

Related Guides

• CAPTCHA Solver Troubleshooting Guide — full overview
• CAPTCHA Solver Low Success Rate — other token rejection causes
• How to Solve reCAPTCHA v2 in Python — full v2 code tutorial
• How to Solve reCAPTCHA v3 in Python — full v3 code tutorial
• Best reCAPTCHA Enterprise Solver — Enterprise solver comparison

Production Readiness Notes

Use reCAPTCHA Solver Token Invalid — Diagnosis and Fixes as a decision and implementation aid, not just as a one-time reference. The practical test for recaptcha solver token invalid is whether the same approach behaves reliably when traffic is messy: rotating sessions, expired tokens, changing widget parameters, intermittent solver delays, and target pages that refresh without warning. For Developer debugging reCAPTCHA token rejection, the safest rollout is to start with a narrow fixture, record every submitted task, and compare the solver response with the browser state that finally submits the form. That makes failures explainable instead of mysterious, especially when a target alternates between visible challenges, invisible checks, and server-side verification.

Evaluation Criteria

A troubleshooting guide should change one variable at a time and record the before-and-after result; otherwise proxy, token, and page-state bugs blur together. For troubleshooting work, the most useful scorecard combines technical acceptance with operational cost. A low nominal price is not enough if retries double the real cost per accepted token, and a fast median solve time is not enough if p95 latency stalls the queue. Track these criteria before you standardize the workflow:

• The challenge subtype, sitekey, action, rqdata, blob, captchaId, or page URL used for each task.
• Median and p95 solve time, separated by provider and target domain.
• Accepted-token rate on the target page, not just successful API responses.
• Retry count, timeout count, zero-balance incidents, and invalid-parameter errors.
• The exact browser, proxy region, and user-agent that submitted the solved token.

Rollout Checklist

Before this guidance moves into a production job, build a small acceptance suite around the pages that matter most. Run it with a fixed browser profile, then repeat with the proxy and concurrency settings you expect in production. Keep the first release conservative: bounded polling, clear timeout handling, and a fallback path when the solver cannot return a usable answer. For troubleshooting, preserve the original request payload, solver response, page URL, sitekey, proxy, and browser fingerprint before changing multiple variables. That checklist keeps the article useful after the first copy-paste, because the integration is judged by end-to-end completion rather than by whether a code sample returned a string.

Monitoring Signals

Healthy CAPTCHA automation is observable. Log the task id, provider, challenge type, target host, queue time, solve time, final submit status, and normalized error code for every attempt. Review those logs in daily batches at first, then move to alerts once the baseline is stable. Sudden drops usually come from target-side changes: a new sitekey, a changed action name, a stricter hostname check, an added managed challenge, or a proxy pool that no longer matches the expected geography. When you can see those shifts quickly, provider switching becomes a controlled decision instead of a late-night rewrite.

Maintenance Cadence

Revisit the setup whenever the target UI changes, when the solver provider changes task names or pricing, or when benchmark data shows a sustained latency or solve-rate shift. Keep one known-good fixture for each CAPTCHA subtype and rerun it after dependency upgrades, browser updates, and proxy changes. If the article is used for vendor selection, repeat the same fixture across at least two providers before renewing a balance or migrating the whole pipeline. That habit keeps recaptcha solver token invalid work aligned with the real target behavior rather than with stale assumptions.