How reCAPTCHA v2 works and how to solve it (coming soon)
reCAPTCHA v2 is Google's classic captcha. It shows a checkbox labelled "I'm not a robot" and, when it is not sure about the visitor, it adds an image challenge. A solver for it has to produce a valid response token that the site can verify with Google. Scarnox support for reCAPTCHA v2 is coming soon. This guide explains how the widget works, the general approaches people use today, and what to expect from a token-based solver.
Scarnox does not solve reCAPTCHA v2 live yet. The only live task type today is PopularCaptcha, proxyless. If your project needs reCAPTCHA v2 now, the approaches below are the realistic options.
How the widget works
The page embeds a container element with a data-sitekey attribute. That sitekey identifies the site to Google. When the widget loads, it runs checks in the browser, looking at the visitor's behaviour, cookies and history, and it sends a risk assessment to Google.
If the assessment is low risk, the checkbox ticks itself and the widget writes a token into a hidden field called g-recaptcha-response. If the assessment is higher risk, the visitor sees an image challenge, such as selecting tiles that contain a particular object. Passing the challenge also writes the token.
The site's backend then sends that token to Google's verification endpoint, along with the site's secret key. Google responds with success or failure. Because verification happens on the server, a form that accepts a token without checking it with Google is not protected by reCAPTCHA at all.
Why it gets flagged
The checkbox is a risk decision, not a puzzle. The usual triggers are:
- a burst of requests from one IP address;
- a new browser session with no cookies or history;
- a browser environment that looks automated, such as a default headless setup;
- a pattern of input that does not look like a person moving a mouse or typing.
Understanding these triggers matters more than the widget itself. If your traffic does not trigger the checkbox, you never see the image challenge.
General approaches that work today
These approaches are used widely, and they are honest ones. They reduce how often a challenge appears on legitimate work.
- Keep real sessions. Reuse cookies and a consistent browser profile over a session, rather than starting fresh on every page.
- Pace your requests. A steady, slow rate looks far more like a person than a burst.
- Use a real browser for the widget. A full browser with normal settings is less likely to be flagged than a stripped-down headless setup. The headless browser detection guide lists the common signals.
- Ask for an exception or a test key. If you own the site, use Google's published test keys in staging. If you do not, ask the owner for an allowlist.
- Use a person in the loop. For low-volume tasks, a human can complete the checkbox and pass the token on. This is slow but reliable.
These approaches do not guarantee that a challenge never appears. They reduce the frequency, which is what keeps a legitimate job stable.
What a token-based solver will do
A token-based solver for reCAPTCHA v2 does what PopularCaptcha does today. It takes the sitekey and page URL, produces a valid g-recaptcha-response token, and returns it to your code. Your code then writes the token into the form and submits it before the token expires.
Scarnox will document the task type and any extra fields in the API reference when reCAPTCHA v2 support ships. Until then, do not build against an assumed interface. The request shape will be similar to the PopularCaptcha example, but check the docs for the exact values.
Checklist for a reCAPTCHA v2 job
When you plan a job that touches a reCAPTCHA v2 form, check these points:
- Is the site yours? If so, use test keys in staging and keep production tests minimal.
- Is the job legitimate? Public data collection and your own workflows are; account abuse and spam are not.
- Is the rate low enough that the checkbox stays quiet?
- Do you have a plan for the image challenge, either a human or a solver once one is live?
- Do you check the server-side verification result, not just the presence of a token?
Common mistakes
The most frequent problem with a reCAPTCHA v2 integration is a token that the site rejects even though it looks correct. Three causes account for most of these. The first is a mismatch between the sitekey and the page URL: the token is bound to the page where the widget was shown, so a sitekey taken from one page and submitted to another will fail. The second is a stale token. Tokens are short-lived, so a script that solves first and then runs a slow sequence of other steps will submit an expired value. The third is a missing server-side check on your end. If your own tests only confirm that a token exists, you will not notice that the verification step is failing.
A second group of mistakes comes from the workflow around the widget. Logging in on one session and then submitting the form from another is a common one, because the verification may depend on the session that loaded the widget. Retrying a rejected form many times in a row also makes the session look suspicious, which can turn a single challenge into a series of them. When something fails, pause, check the page state, and try once more with fresh values.
Scrape responsibly
If the form is part of a scraping job, check robots.txt and the site's terms before you start. Keep the rate low, and do not collect personal data you do not need. The is web scraping legal guide covers the main considerations.