reCAPTCHA v3 Score Explained: What Lowers It

A reCAPTCHA v3 score is a number between 0.0 and 1.0 that Google attaches to each token, estimating how likely the interaction is to be legitimate: near 1.0 looks human, near 0.0 looks automated. reCAPTCHA v3 never blocks anyone itself. The website reads the score when it verifies the token and decides what to do — allow, ask for a second factor, or reject. This guide explains what the score is built from, why so many scores are exactly 0.1, 0.3, 0.7 or 0.9, what actually pushes a score down, and how to read it correctly whether you run the site or the automation hitting it.

What a reCAPTCHA v3 score means

The score is a risk estimate for one interaction, not a pass or fail. Google's reCAPTCHA v3 documentation describes it plainly: 1.0 is very likely a good interaction, 0.0 is very likely a bot, and the site chooses the threshold. The suggested default threshold is 0.5, which Google recommends tuning against your own traffic.

The score belongs to the token. It is fixed when the page calls grecaptcha.execute() with an action name, and the site sees it only when its server verifies that token. Nothing on the page reveals it, so a visitor never knows what they scored.

Why scores are only 0.1, 0.3, 0.7 or 0.9

Because most sites use free keys, and free keys only return four values. Google Cloud's guide to interpreting assessments says reCAPTCHA has 11 score levels from 0.0 to 1.0, but without a billing account only 0.1, 0.3, 0.7 and 0.9 are available. Adding billing unlocks all 11 levels and the reason codes described below; Google's tier comparison lists four levels for the Essentials tier and eleven for Premium and Enterprise.

So a score that "jumped from 0.7 to 0.3" did not move a little — it dropped two of only four steps. That coarse scale is also why thresholds such as 0.5 and 0.6 behave identically on free keys: both sit between 0.3 and 0.7.

What the score is built from

The score comes from signals across the session, not from any single check. Google does not publish the model, so treat any list as indicative, but the factors that consistently matter are:

• Network: the reputation of the IP address. Datacenter ranges, busy proxies and VPN exits start from a weaker position than home or mobile connections.
• Browser and history: whether the browser looks like a normal one with a normal history. A fresh profile with no cookies on every visit looks unusual.
• Behaviour on the site: how the visitor reached the page and moved through it. Google says v3 learns from interactions with your site, which is why it recommends running it on several pages, not only the protected form.
• The site itself: the model is tuned to each site's traffic, so the same visitor can score differently on two sites.

What a reason code tells you

Reason codes say why a score is low, but only on paid tiers. Google lists, among others, AUTOMATION (the interaction matches an automated agent), UNEXPECTED_ENVIRONMENT (an illegitimate environment), TOO_MUCH_TRAFFIC (more traffic than normal from the source), UNEXPECTED_USAGE_PATTERNS and LOW_CONFIDENCE_SCORE (too little traffic to judge well). Google also notes that only some scores come with reason codes, which explains forum threads where low scores arrive with no reason at all.

Common reasons real users score low

Real people score low for the same reasons bots do: they look unusual. VPN users, people on shared corporate or campus networks, privacy-hardened browsers and in-app browsers all start at a disadvantage. In a long-running thread on Google's own security community from mid-2025, site owners reported a sudden rise in sub-0.5 scores concentrated on iOS and inside the TikTok in-app browser, with no change to their sites — a reminder that scores shift when Google's model or the client platform changes, not only when your traffic does.

The opposite happens too: another thread in the same community describes clearly automated sign-up traffic scoring 0.7. A score is a probability, not proof, which is why Google recommends acting on it quietly rather than as a hard gate.

How to use the score if you run the site

Use the score to choose a response, not to block outright. Google's suggestions include asking for two-factor authentication on low-scoring logins and sending low-scoring comments to moderation. A practical setup:

Always check the returned action against the one you expected; Google treats a mismatch as a sign of falsified traffic. And remember tokens expire two minutes after they are issued and verify only once, so execute reCAPTCHA when the user acts, not on page load.

What this means for automation

For automation, the score is decided when the token is generated, and it is graded against everything Google can see at that moment. Running a script from a cloud server with a fresh browser profile is close to the worst case: datacenter IP, no history, no prior interaction. That is the main reason scrapers report v3 scores stuck at 0.1 or 0.3.

Two practical points follow. First, send the right action: if the page calls execute with login, a token produced for any other action fails the site's action check whatever its score. Second, request the token late, right before the request that carries it, because two minutes passes quickly in a multi-step flow.

A solving API can generate a v3 token for a sitekey, URL and action you supply — CaptchaNo's reCAPTCHA v3 solver lets you set the action and a minimum score of up to 0.9. Be clear about the limits: neither you nor the solver can see the score Google assigned, only the site can, and many sites combine the score with their own IP, cookie and rate checks. If those checks fail, a good score will not save the request. Our post on why captcha tokens get rejected covers those session checks, and reCAPTCHA Enterprise covers the paid variant, which our v3 type does not handle.

How CaptchaNo handles v3

You send type: "recaptcha_v3" with the page URL, the sitekey, the page's action and an optional minScore; you get back a token, billed only when a token is produced. The price is the same whatever minimum you request. Request details are in the API reference.

Frequently Asked Questions

What is a good reCAPTCHA v3 score?

Google treats scores near 1.0 as very likely legitimate and suggests 0.5 as a starting threshold. On free keys the only possible values are 0.1, 0.3, 0.7 and 0.9, so in practice 0.7 and 0.9 pass most sites and 0.1 and 0.3 trigger extra checks. Each site sets its own threshold, so there is no universal pass mark.

Why is my reCAPTCHA v3 score always 0.1 or 0.9?

Sites without a Google Cloud billing account receive only four score values: 0.1, 0.3, 0.7 and 0.9. A score stuck at 0.1 usually points to a distrusted network or a brand-new browser profile. A constant 0.9 is common with Google's test keys and on low-traffic sites where the model has little to compare against.

Can I see my own reCAPTCHA v3 score?

Not from the page. The score is only revealed to the website's server when it verifies the token with Google, and the site decides whether to show or log it. Some third-party test pages verify a token for you and print the result, which helps you compare networks and browsers.

Does the action name affect the score?

Google grades each action separately, and the site should check that the returned action matches the one it expects. A mismatched action is normally rejected by that check regardless of the score, so always send exactly the action string the page passes to execute, including its case and any slashes.

How long is a reCAPTCHA v3 token valid?

Two minutes, and it can be verified only once. Google advises calling execute when the user actually performs the action rather than on page load, because a token generated early can expire before the form is submitted. In automation, generate the token immediately before the request that uses it.

Generate v3 tokens for your own workflows

Start a free CaptchaNo trial to request v3 tokens with the action and minimum score your target expects, for automation you are authorised to run. Rates are on the pricing page.