reCAPTCHA v3 never shows a puzzle. It watches how a page is used, returns a score for each request, and leaves the decision to the site. So there is nothing on the screen to solve, and searches for a "bypass" mostly lead to people selling one. This page explains what v3 actually returns, from Google's own documentation, and what a proxy can and cannot change. It ends with the routes to the data that hold up.
We also measured what reCAPTCHA v3 costs a page view in bytes, on Google's own demo page. On October 23, 2026, a first visit pulled about 416 KB of reCAPTCHA, and a repeat visit still about 30 KB. If you pay per GB of traffic, that number is yours to carry.
What reCAPTCHA v3 returns
Google describes it in one line: "reCAPTCHA v3 returns a score for each request without user friction". The scale runs from 0.0 to 1.0: "1.0 is very likely a good interaction, 0.0 is very likely a bot". The site loads Google's script, the script hands the page a token, and the site's server sends that token to Google to get the score back.
A few rules sit around that score:
- The token is short-lived. Google: "Each reCAPTCHA user response token is valid for two minutes, and can only be verified once to prevent replay attacks."
- Each request carries an action. The site names what was happening, such as a login or a search, and checks that the action matches.
- Free keys see four levels. Google Cloud's documentation says reCAPTCHA "has 11 levels for scores with values ranging from 0.0 to 1.0", but only "0.1, 0.3, 0.7, and 0.9" are available until the site adds a billing account.
- The threshold belongs to the site. "By default, you can use a threshold of 0.5", Google says, and then adjust it to the site's own traffic.
What the site does with the score
Google's guide gives sites a table of uses, and scrapers are named in the first row. For a homepage it suggests to "See a cohesive view of your traffic on the admin console while filtering scrapers". For a login, it suggests requiring "2-factor-authentication or email verification" when scores are low. For comments, it suggests sending risky ones "to moderation".
The same guide tells sites to "take action behind the scenes instead of blocking traffic". So a low score rarely announces itself. A scraper may get an empty result, a form that never submits, or a request that waits in a review queue. Our guide to why you keep hitting reCAPTCHA covers the visible challenges, and this page covers the score behind them.
Sites on reCAPTCHA Enterprise see more than the number. Each assessment can come back with reasons. One is AUTOMATION: "The interaction matches the behavior of an automated agent". Another is TOO_MUCH_TRAFFIC: "Traffic volume from the event source is higher than normal".
Why a scraper meets it
A plain HTTP client never runs the page's JavaScript, so it never gets a token. A site that verifies tokens turns that request away before any score exists. A real browser gets a token and a score, and the site decides from there.
That is the whole design. v3 gives the site a judgment about each interaction. By setting it up, the site has said it wants to hear about automated ones.
What a proxy changes, and what it does not
A proxy changes one thing: the address the request comes from. In reCAPTCHA Enterprise, the site itself sends that address to Google. The assessment request carries the visitor's userIpAddress and userAgent, both supplied by the site.
Google does not publish how it weighs any input. Guides that say v3 "makes decisions based on your IP and ASN" state as fact what Google has never published. What is safe to say is narrower. An address is one input among several. A residential address changes nothing about the browser, the page's script, the session or the behavior.
There is a plainer point too. A site that runs v3 on a page has said how it wants that page used. The reliable ways to its data run through the site: its API, a data export, or the owner's permission. Where your target is a platform we already cover, our scraper APIs return the public data in one call.
reCAPTCHA v2 against v3
Google lists four types: "reCAPTCHA v3, reCAPTCHA v2 ('I'm not a robot' Checkbox), reCAPTCHA v2 (Invisible reCAPTCHA badge), and reCAPTCHA v2 (Android)".
| reCAPTCHA v2 | reCAPTCHA v3 | |
|---|---|---|
| What the visitor sees | A checkbox, or an invisible badge that can raise an image challenge | Nothing; the check runs in the background |
| What the site gets | Pass or fail for the challenge | A score from 0.0 to 1.0 for each action |
| Who decides | The challenge | The site, using its own threshold |
| Free-tier detail | The widget shows a quota warning when over quota | site_verify may return a static 0.9 when over quota |
What reCAPTCHA v3 costs a page view, measured
Every page that loads reCAPTCHA pulls Google's script before any score exists. We measured how much on Google's own public v3 demo page. A separate headless Chrome 155 with a temporary profile loaded the page twice, and we added up every request to Google's reCAPTCHA addresses. The demo runs reCAPTCHA as soon as it loads, as a site would. We clicked nothing and kept no score.
- reCAPTCHA v3
- hCaptcha
The first visit was mostly one file: recaptcha__en.js at 347.5 KB, then 34.7 KB of styles and the 27.9 KB frame. On a repeat visit the script came from the cache. The frame and the token request did not, so about 30 KB went out again. A browser that starts with an empty profile pays the full 416 KB each time.
Through any proxy billed per GB, those bytes count like any others, whether residential or mobile. A thousand first visits come to about 0.4 GB for reCAPTCHA alone. Residential Premium costs $1.49/GB for one GB, falling to $1.00/GB at 1,000 GB+. Our hCaptcha guide measured the same for hCaptcha.
Why a score can sit at 0.9
Google's FAQ explains one case that confuses site owners and scrapers alike. A v3 key past its monthly quota "may fail open by returning a static score 0.9 and an error message 'Over free quota.' for the remainder of the month". It adds: "There are no user-visible indications when v3 sites are over quota." The free tier covers 10,000 assessments a month.
So a steady 0.9 for every visitor tells a site owner to check the error field before trusting the score. It says nothing about any one visitor.
If you run the site
Google's advice is to start quietly. reCAPTCHA "learns by seeing real traffic on your site", so scores in staging or soon after setup "may differ from production". Run v3 without acting on it first, read the scores in the admin console, then set a threshold for each action. Verify the token on your server within two minutes, check that the action matches, and read the error field before the score.
The routes that hold up
- The site's API or export. Many sites publish the same data through a documented interface with its own limits.
- Permission. For a one-off research project, the site owner can allow your client.
- A platform we cover. Our scraper APIs return public data from the platforms they list.
- Pages you may automate. Our Playwright guide shows how to route a browser through a proxy, and proxies for web scraping covers the rest of the workflow. Test any proxy before a run with our proxy checker.
Sources
- Google for Developers: reCAPTCHA v3, read October 23, 2026.
- Google for Developers: Verifying the user's response, read October 23, 2026.
- Google for Developers: reCAPTCHA FAQ, read October 23, 2026.
- Google for Developers: Choosing the type of reCAPTCHA, read October 23, 2026.
- Google Cloud: Interpret assessments for websites, read October 23, 2026.
- Google Keyword Planner, worldwide monthly searches, read October 23, 2026.
- Our own runs on October 23, 2026: Google's public reCAPTCHA v3 demo page loaded twice per run, three runs, in Chrome 155 headless with a temporary profile; no score read, nothing clicked.
