reCAPTCHA v3 Score Explained

How the score is produced

Google’s reCAPTCHA v3 guide sets out the mechanics. The page calls execute with an action name such as login or checkout. The token it receives expires after two minutes, so sites are told to call it when the user acts, not when the page loads. The server sends the token to Google and gets back a response with these fields:

• success: whether the token was valid for this site
• score: 0.0 to 1.0
• action: the action name, which the server should check matches what it expected
• challenge_ts and hostname: when and where the token was created
• error-codes: present when something failed

Google adds that reCAPTCHA learns from the real traffic on each site, so scores in staging or soon after installation differ from production. That is why a score is not portable: it reflects how your session compares with that site’s visitors.

That v3 developer page is now marked deprecated and points to the documentation for Google Cloud Fraud Defense, which Google introduced on April 22, 2026 as the next evolution of reCAPTCHA. Google says existing customers need no migration and their site keys and integrations stay as they are. The same announcement adds a QR code challenge that asks a human to confirm when an AI agent is flagged, and policy controls for agent traffic.

Score levels and the reasons Google gives

The score is not continuous. Google Cloud’s guide to interpreting assessments says reCAPTCHA has 11 score levels from 0.0 to 1.0, and that only four of them, 0.1, 0.3, 0.7 and 0.9, are available before a billing account triggers a security review. Many sites therefore see one of four values, which makes small changes in your setup invisible until they cross a band.

With billing enabled, assessments can include reason codes. These are the closest thing to an official list of what lowers a score:

What sites do with the number

Google’s guidance is to start with a threshold of 0.5, run reCAPTCHA without acting on it, study the traffic in the admin console, and then choose thresholds per action. The Cloud documentation adds that sites can act in the background instead of blocking. In practice that produces a ladder rather than a wall. The v3 guide’s own examples: on a login with a low score, require two-factor or email verification; on a social site, limit friend requests and send risky comments to moderation.

So a low score rarely shows as an error message. It shows as an extra verification email, a code by SMS, a visible CAPTCHA, a post held for review or a checkout that quietly fails. If one action on a site keeps asking for more proof while others work, that action probably has a stricter threshold.

What lowers a score for real users and proxied sessions

Google does not publish its inputs, so the honest list is built from the reason codes above:

• Automation traces. The W3C WebDriver standard makes navigator.webdriver true under remote control, readable by any script. Headless modes and replayed input fit the AUTOMATION code.
• Busy or shared addresses. VPN exits, office networks and carrier addresses shared by many subscribers can exceed normal traffic for a site, the TOO_MUCH_TRAFFIC case.
• Odd environments. Privacy patches that alter browser APIs can look like an illegitimate environment even when the person is real.
• Straight-to-target behavior. Opening a login form directly and submitting within a second does not match the site’s usual visitors.
• IP changes during a session. A token created on one address and submitted from another is an unusual pattern, and rotating proxies produce exactly that.

What raises it, and how to check yours

For people: use a current mainstream browser, allow the site’s scripts and Google’s reCAPTCHA domains, keep cookies, turn off the VPN for sites that keep asking for more, and let pages load before acting.

For site owners: call execute at the moment of the action, verify the action name, and run reCAPTCHA in the background of normal pages as Google recommends, so the model sees ordinary browsing as well as forms. Choose thresholds from your own data instead of copying 0.5.

For proxy users: keep one exit address for the whole session and rotate between tasks. With mobile proxies from Coronium, set the rotation timer (60 seconds minimum) longer than the session, or rotate from the dashboard or API when a task ends. Never open the rotation link in a tool that fetches link previews, since every GET rotates the line.

Checking your own number is limited by design. Public test pages report the score for their own site key and their own traffic, and a test page without billing sees only the four basic levels. Use them to compare two setups side by side, not to predict another site’s decision. For the bigger picture of where challenges come from, see why CAPTCHAs keep appearing.

Frequently asked questions