reCAPTCHA v3 Score: How Scoring Works and Tips for Developers
Understand reCAPTCHA v3's scoring system — how Google assigns scores from 0.0 to 1.0, what factors influence them, and how to request specific minimum scores via API.
Understanding the reCAPTCHA v3 score system is critical for anyone solving v3 challenges programmatically, because a valid token with a low score will still be rejected by the target site. Unlike v2, which produces a binary pass or fail, v3 assigns every interaction a score from 0.0 (very likely a bot) to 1.0 (very likely human). The site owner decides what score to accept, and your automation needs to produce tokens that meet that threshold.
How reCAPTCHA v3 Scoring Works
When a page loads reCAPTCHA v3, Google’s JavaScript begins collecting behavioral signals immediately. These signals are analyzed in real time to build a risk profile for the current session. When the site calls grecaptcha.execute(), Google returns a token that encodes the current risk assessment. The site’s server then sends this token to Google’s verification API, which responds with a score.
The scoring happens on Google’s servers, not in the browser. The JavaScript only collects and transmits signals — the actual score computation is opaque and proprietary.
The Score Range
- 1.0: Very likely a real human with normal browsing behavior
- 0.7–0.9: Probably human, most sites accept this range
- 0.4–0.6: Uncertain, some sites may challenge or add friction
- 0.1–0.3: Likely automated, most sites will block or flag
- 0.0: Almost certainly a bot
Google does not publish the exact algorithm, but the scoring is based on a machine learning model trained on billions of interactions across all sites using reCAPTCHA.
Factors That Influence the Score
While Google keeps the exact scoring algorithm secret, testing and observation reveal several factors that consistently affect v3 scores.
Browser Environment
The browser’s fingerprint matters significantly. Signals include:
- User agent string: Standard browser user agents score higher than headless browser signatures or missing user agents.
- JavaScript API availability: Google checks for the presence of standard Web APIs. Headless browsers that disable or modify APIs (like
navigator.webdriver) trigger lower scores. - Canvas and WebGL fingerprints: Inconsistencies in rendering capabilities relative to the declared user agent raise flags.
- Screen resolution and window size: Unusual dimensions (like 1x1 pixel windows) signal automation.
Behavioral Signals
v3 monitors how the user interacts with the page over time:
- Mouse movements: Natural mouse movement patterns (curves, varying speed, slight jitter) score higher than straight lines or absence of mouse events.
- Scroll behavior: Scrolling through page content before interacting with a form looks more human than jumping directly to a submit button.
- Typing patterns: Keystroke timing that varies naturally scores better than instant form fills.
- Time on page: Spending a reasonable amount of time on the page before triggering the CAPTCHA improves scores. Instant form submission after page load is a red flag.
Session and History
- Google cookies: Users logged into a Google account with browsing history score significantly higher. Fresh browser profiles with no cookies score lower.
- IP reputation: IP addresses associated with data centers, VPNs, or previously flagged activity receive lower scores. Residential IPs score higher.
- Previous interactions: If the same browser session has already passed reCAPTCHA challenges on other pages of the same site, subsequent scores tend to be higher.
The Action Parameter
The action parameter passed to grecaptcha.execute() labels the interaction context. Google uses this to compare the current interaction against the expected behavior for that action. For example, a login action where the user navigated from the homepage and filled in credentials will score differently than a login action triggered immediately on page load with no prior interaction.
How Sites Use the Score
Site owners receive the score from Google’s verification API and implement their own logic. Common patterns include:
Hard threshold: Block all requests below a score (e.g., reject if score < 0.5). This is the simplest approach.
Tiered response: Different actions for different score ranges. For example:
- Score >= 0.7: Allow the action immediately
- Score 0.3–0.7: Require email verification or a v2 challenge
- Score < 0.3: Block entirely
Logging only: Some sites use v3 purely for analytics, recording scores without blocking anyone. They use the data to tune their thresholds over time.
The score threshold is entirely up to the site owner. There is no universal cutoff. This means you need to determine the target site’s threshold through testing if it is not documented.
Using the minScore Parameter When Solving
When submitting a reCAPTCHA v3 task to a CAPTCHA solving API, the minScore parameter tells the solver the minimum acceptable score. The solver will attempt to produce a token that meets or exceeds this threshold.
import requests
import time
API_KEY = "YOUR_UCAPTCHA_API_KEY"
BASE_URL = "https://api.ucaptcha.net"
response = requests.post(f"{BASE_URL}/createTask", json={
"clientKey": API_KEY,
"task": {
"type": "RecaptchaV3TaskProxyless",
"websiteURL": "https://example.com/login",
"websiteKey": "6LcR_RsTAAAA...",
"pageAction": "login",
"minScore": 0.7
}
})
task_id = response.json()["taskId"]
while True:
time.sleep(5)
result = requests.post(f"{BASE_URL}/getTaskResult", json={
"clientKey": API_KEY,
"taskId": task_id
})
data = result.json()
if data["status"] == "ready":
token = data["solution"]["gRecaptchaResponse"]
score = data["solution"].get("score")
print(f"Token: {token[:60]}...")
print(f"Achieved score: {score}")
break
elif data["status"] != "processing":
print(f"Error: {data}")
break
Choosing the Right minScore
- 0.9: Use only when you know the site requires it. Harder to achieve, slower solves, and higher cost. Most providers cannot guarantee 0.9 consistently.
- 0.7: A safe default for most sites. The majority of websites that use v3 set their threshold between 0.5 and 0.7.
- 0.5: Works for sites with lenient thresholds. Faster and cheaper solves.
- 0.3: The minimum practical value. Only useful if the site logs scores but does not block.
If you do not know the site’s threshold, start with 0.7. If tokens are accepted, you can try lowering to 0.5 to reduce cost. If tokens are rejected, increase to 0.9.
The Action Parameter Is Critical
The pageAction parameter is not optional for v3 — it must match the action string used in the site’s grecaptcha.execute() call exactly. A mismatched action will produce a token that Google marks with a different action label than the server expects, resulting in rejection regardless of the score.
Finding the Correct Action
Method 1: Search the JavaScript
Look for grecaptcha.execute calls in the page source:
grecaptcha.execute('6LcR_RsTAAAA...', { action: 'submit_form' })
The second argument’s action property is what you need.
Method 2: Network inspection
In DevTools, look at the payload of requests to Google’s reCAPTCHA endpoints. The action is included in the request parameters.
Method 3: Verify API response
If you have access to the server-side verification, the Google API response includes the action that was submitted with the token:
{
"success": true,
"score": 0.7,
"action": "submit_form",
"challenge_ts": "2026-10-15T12:00:00Z",
"hostname": "example.com"
}
Common Action Values
Sites frequently use these action strings:
login/signinregister/signupsubmit/submit_formcheckout/purchasecontact/contact_formhomepage/pageviewsearch
Score Optimization Tips
When solving v3 at scale, small improvements in average score translate to meaningful gains in success rate and cost efficiency.
Use residential proxies: If the target site checks IP consistency, route both the solve and the form submission through the same residential proxy. Data center IPs consistently receive lower v3 scores.
Match the action exactly: Even a slight difference (like Login vs login) can affect the score. Action strings are case-sensitive.
Avoid rapid-fire solves: Submitting many v3 tasks for the same site in quick succession from the same session or IP can trigger Google’s abuse detection, lowering scores across all requests.
Use uCaptcha’s routing presets: The “Reliable” preset routes v3 tasks to providers with the highest average scores for that specific site. The “Fastest” preset may return lower scores if the fastest provider is not the most accurate.
Warm up the session: If using a headless browser, load the page, simulate some mouse movements and scrolling, wait a few seconds, and then trigger the reCAPTCHA. This produces higher scores than solving immediately on page load.
Conclusion
reCAPTCHA v3 scoring adds a layer of complexity that v2 does not have. A valid token is not enough — it must carry a score that meets the target site’s threshold. Success depends on three things: using the correct pageAction, requesting an appropriate minScore, and routing through a provider that can achieve high scores consistently. uCaptcha’s auto-routing handles the provider selection, comparing scores and success rates across CapSolver, 2Captcha, AntiCaptcha, CapMonster, and Multibot to find the best match for each task. For complete code examples covering v3 and all other reCAPTCHA variants, see our comprehensive guide to solving reCAPTCHA v2 and v3.
Related Articles
Invisible reCAPTCHA: How It Works and How to Solve It
Learn how invisible reCAPTCHA works under the hood and how to solve it programmatically using CAPTCHA solver APIs with the isInvisible parameter.
Pillar Guide
How to Solve reCAPTCHA v2 and v3 Programmatically
Complete guide to solving reCAPTCHA v2 (checkbox, invisible) and v3 (score-based) programmatically using a CAPTCHA solver API. Includes Python and JavaScript code examples.