Modern CAPTCHA services: reCAPTCHA, Turnstile, hCaptcha and SmartCaptcha — how they work and which to choose

Modern CAPTCHA has long ceased to be just an “exercise in recognizing crooked letters.” Today it’s a full-fledged anti-bot mechanism that analyzes not only the explicit user action but also the context of the request: browser behavior, frequency and nature of interactions, network signals, and in some cases — additional device-environment signals. Cloudflare Turnstile, for example, documents Ephemeral IDs separately — short-lived identifiers to strengthen anti-fraud analysis without classic cookies — and Google reCAPTCHA Enterprise is positioned not as a “widget with pictures” but as part of a protection system against scraping, credential stuffing, fake registrations and other abuse.

Below is an analysis of the main market players, the real integration flow, and the details that break half of implementations.

Google reCAPTCHA (v2 / v3 / Enterprise)

Google reCAPTCHA remains one of the most well-known solutions on the market. The service has several integration modes: v2 with a checkbox, invisible reCAPTCHA, v3 with a score model, and the Enterprise branch tied to Google Cloud. It is important to understand that today the boundary between a “simple CAPTCHA” and a full risk assessment at Google is quite blurred: even official Google advises interpreting the score and building your server logic around it, rather than relying solely on the fact the widget was passed.

• reCAPTCHA v2 (“I’m not a robot”) The classic checkbox variant. If the check is uncertain about the user, an additional challenge may be shown. Google also has invisible reCAPTCHA, which belongs to the v2 family and can be invoked without an explicit checkbox.

• reCAPTCHA v3 Fully invisible mode. Instead of “solve the pictures” it returns a score that you interpret on your side. Google emphasizes that v3 tokens must be requested at the time of the user action, not on page load, because the token lives only 2 minutes.

• reCAPTCHA Enterprise This is already an abuse and fraud protection system, not just a widget. In official materials Google Enterprise is explicitly positioned as a tool against scraping, credential stuffing, account takeover, fake account creation and payment fraud. For sites the server typically creates a risk assessment and based on that decides — allow the request, require additional verification, or block it.

From a practical standpoint reCAPTCHA has two persistent downsides. The first is privacy: the service is closely tied to Google’s infrastructure, and some teams categorically do not want to pull such a dependency into public forms. The second is availability across regions and networks: if Google services are slow or unreliable for your users, the CAPTCHA will degrade with them. At the same time Google officially states GDPR-compliance for the cloud version of reCAPTCHA, so the question here is less about “legal or illegal” and more about architectural choice and trust model.

Cloudflare Turnstile

Cloudflare Turnstile in recent years has become the most notable direct alternative standard. Its strong point is minimal friction for the user. Cloudflare explicitly states that Turnstile can be integrated into any site without mandatory use of Cloudflare CDN, and the service often works without showing a traditional CAPTCHA at all.

Turnstile has several operating modes:

• Non-interactive — the user doesn’t press anything at all.
• Managed — an interactive check may appear if suspicion arises.
• Invisible — fully hidden mode.

As of March 2026 Turnstile has a free plan and an Enterprise plan. The free option is officially suitable not only for tests and personal sites, but for most production applications; Enterprise is needed for high volumes, complex host management, advanced bot detection and compliance scenarios. So it’s more accurate to say not “the service is completely free forever without caveats”, but “there is a very generous free tier and a separate enterprise level.”

From a privacy perspective Cloudflare has a strong marketing thesis: Turnstile does not collect data for ad retargeting. Additionally the service has Ephemeral IDs — short-lived identifiers tied to an account that help catch abuse patterns without classic cross-site tracking. This does not mean “no data is collected at all”, but it means the architecture is noticeably less toxic for privacy discussions than the classic Google approach.

Another plus — availability. Cloudflare officially states Turnstile’s conformance to WCAG 2.2 AAA, which for public forms and B2C services is not just a nice bonus but a working selection criterion.

hCaptcha

hCaptcha is another major alternative player that emphasizes privacy and abuse protection for large clients. In the basic scenario it is very similar to classic CAPTCHA integration: a frontend widget, a token on the server, server-side validation. But at enterprise level passive modes without explicit challenge, risk scoring, customizable threat models, advanced analytics and additional APIs are available. So hCaptcha is not just a Google replacement but a platform for abuse protection.

hCaptcha does have a monetization model in which site owners can earn payments for participating in the labeling ecosystem and challenge traffic. But this should not be presented as the main reason to choose it. In practice hCaptcha is chosen more often not for potential income but to replace Google, for regional availability and a more flexible privacy stance.

From an accessibility standpoint hCaptcha offers not only audio verification but other ways to pass checks, including text-based options. This is an important nuance: in 2026 merely having an “audio CAPTCHA” can no longer be considered sufficient evidence of good accessibility.

Yandex SmartCaptcha

Yandex SmartCaptcha is a strong candidate for the RU-segment and generally for scenarios where data localization, good accessibility from Russia and integration with Yandex Cloud infrastructure are critical. Yandex official documentation describes several modes: invisible captcha, intermediate checks like a checkbox or slider, and more complex tasks for suspicious requests. The service page lists task types separately, including text recognition, slider, silhouettes and kaleidoscope.

It’s important not to confuse two things. First: SmartCaptcha is indeed convenient for Russian projects because it lives in the Yandex Cloud ecosystem. Second: the phrasing “SmartCaptcha automatically makes your project compliant with 152-FZ” is too blunt. More correctly: Yandex Cloud as a whole claims compliance with the requirements of 152-FZ and provides infrastructure for localization and processing of personal data in Russia, which makes SmartCaptcha a natural choice for such scenarios. But legal responsibility and a full compliance model still remain with the system owner.

From a UX perspective SmartCaptcha’s strong point is a focus on minimal friction. Yandex explicitly writes on the service page that in many cases the user only needs to press “I’m not a robot”, and a complex task is shown only when a bot is suspected.

2. How integration really works

Any modern CAPTCHA works in a two-step scheme. If you implemented only the frontend widget and did not do server-side validation, you effectively have no protection. This is stated strongly in Cloudflare Turnstile’s documentation: without calling Siteverify the configuration is considered incomplete, and the client widget itself does not provide protection. The same logic applies to Google reCAPTCHA, hCaptcha and Yandex SmartCaptcha.

Step 1: client side

On the frontend you include the service JS library and render the widget or invisible mechanic. After a successful check the service places a token into a hidden form field or returns it via a callback. For example:

• g-recaptcha-response for Google reCAPTCHA.
• cf-turnstile-response for Cloudflare Turnstile.
• h-captcha-response for hCaptcha.
• smart-token for Yandex SmartCaptcha.

Then this token must be sent to your backend together with the form payload: login, password, feedback message, order data, etc.

Step 2: server-side verification

This is the main step. Your backend must send the token to the CAPTCHA provider’s server and ensure that the token:

• exists;
• has not expired;
• has not been used again;
• belongs to the expected action or site;
• passed validation.

Below are typical verification endpoints.

Google reCAPTCHA

curl -X POST https://www.google.com/recaptcha/api/siteverify \
  -d "secret=<secret_key>" \
  -d "response=<token>" \
  -d "remoteip=<user_ip>"

reCAPTCHA returns JSON with a success field, and for v3 and Enterprise-like scenarios score and assessment context are also important. The token lives 2 minutes and can be verified only once.

Cloudflare Turnstile

curl -X POST https://challenges.cloudflare.com/turnstile/v0/siteverify \
  -d "secret=<secret_key>" \
  -d "response=<token>" \
  -d "remoteip=<user_ip>"

Server-side verification is mandatory for Turnstile. The token expires after 5 minutes and is single-use.

hCaptcha

curl -X POST https://api.hcaptcha.com/siteverify \
  -d "secret=<secret_key>" \
  -d "response=<token>" \
  -d "remoteip=<user_ip>"

hCaptcha tokens by default also live 120 seconds, and reusing a token returns a separate already-seen-response error.

Yandex SmartCaptcha

curl -X POST https://smartcaptcha.cloud.yandex.ru/validate \
  -d "secret=<server_key>" \
  -d "token=<token_from_form>" \
  -d "ip=<user_ip>"

Yandex indicates that a SmartCaptcha token is valid for 5 minutes and can be used only once. The response will contain JSON with status, and you should proceed with processing the form only if the status is ok.

3. What exactly to check on the backend

The most common integration mistake is that the developer checked the token field is not empty and stopped there. This is not protection. The correct sequence is:

1. Accept the token from the frontend.
2. Send it to the provider’s API.
3. Check validation success.
4. Ensure the token is not expired and not reused.
5. For score-based solutions — interpret the score on your side.
6. Only after that process the original request.

For reCAPTCHA v3 and enterprise scenarios it is especially important not to turn the score into a magical number. The threshold depends on context. For a comments form you can allow more risky traffic, but for login, password recovery, registration or payment the thresholds and response actions should be stricter. Google explicitly writes that the score should be interpreted based on the specifics of your site and your traffic.

4. Important technical nuances people forget

The token cannot just be “passed through”

All major providers make tokens short-lived and single-use. Typical lifetime for Google and hCaptcha is 2 minutes. For Turnstile and SmartCaptcha it’s 5 minutes. Re-validating the same token will either fail or return a reuse/expired error. This is done specifically to protect against replay attacks.

Timeouts on requests to CAPTCHA API are mandatory

If the external CAPTCHA API is unavailable from your datacenter, a hanging backend easily becomes a DoS against itself. Therefore you should set a short timeout on outbound requests to the CAPTCHA service. Yandex documentation explicitly includes an example with CURLOPT_TIMEOUT, and in real practice 1–3 seconds is a workable range for public forms. What to do on error depends on the operation type:

• fail close — reject the request if the CAPTCHA API is unavailable;
• fail open — allow the request, but with additional restrictions;
• soft fail — ask to resubmit the form, request an alternative check, or require a second factor.

For login, registration, password reset, checkout and API write operations it’s usually better to fail close or soft fail. For newsletter signup or secondary forms sometimes fail open with rate limiting and logging is acceptable.

CAPTCHA is not a full anti-bot system

Any CAPTCHA is only one layer of protection. Google, Cloudflare, hCaptcha and Yandex all work best in combination with other measures:

• rate limiting;
• IP / ASN reputation;
• device / session anomalies;
• behavioral signals;
• limits on registration, login, and form submission rates;
• WAF and anti-fraud rules;
• separate rules for anonymous networks, proxies and datacenter IPs.

If you have a serious bot problem, a single CAPTCHA will not solve it. Live anti-CAPTCHA services, device farms and proxied browsers have long been able to pass basic checks. CAPTCHA should serve as an additional barrier and as a signal source for your server logic.

Accessibility is already part of security

A bad CAPTCHA not only cuts conversion but also breaks accessibility. Cloudflare declares WCAG 2.2 AAA for Turnstile. hCaptcha develops accessible verification methods including text-based options. Yandex SmartCaptcha highlights accessibility as a standalone product aspect. Against this background, “old” visual CAPTCHAs with strange symbols already look like technical debt.

CSP can break integration

If you have a strict Content-Security-Policy, the widget may not load at all. For Turnstile Cloudflare officially recommends either nonce-based CSP or explicitly adding the domain to script-src and frame-src. Yandex SmartCaptcha JS loads from smartcaptcha.cloud.yandex.ru, and this must also be considered in the script loading policy.

For example, a typical Turnstile setting would look like:

Content-Security-Policy:
  script-src 'self' https://challenges.cloudflare.com;
  frame-src https://challenges.cloudflare.com;

And for SmartCaptcha you need to allow loading the script and related resources from the Yandex Cloud domains used by the widget.

Test keys and staging environment

Another common mistake is using production keys in automated tests. Google has official test keys for v2, and Cloudflare Turnstile documents dummy sitekeys and secret keys for testing. For v3 Google recommends creating a separate key for the test environment because the score without real traffic will still be unrepresentative.

5. Practical recommendations for choosing

When to choose Cloudflare Turnstile

Turnstile is a very strong default choice for most modern web projects. It’s simple to integrate, does not require Cloudflare CDN, often works without explicit challenges, has a strong accessibility position and is convenient where you do not want to pull a Google dependency. For marketing sites, SaaS, user dashboards, login forms, feedback and registration it’s currently one of the most pragmatic options.

When to choose Google reCAPTCHA

reCAPTCHA makes sense if you’re already deep in the Google Cloud ecosystem, need mature enterprise-level protection, or are building more complex anti-fraud logic around assessments and risk scoring. But in public forms and global B2C scenarios alternatives increasingly win — simply due to UX, privacy concerns and regional availability.

When to choose hCaptcha

hCaptcha is logical where privacy matters, you need a Google replacement without losing abuse protection, and wider capabilities for large clients — passive modes and customizable threat models. The service’s monetization exists, but for a working project it’s secondary.

When to choose Yandex SmartCaptcha

SmartCaptcha is a reasonable choice for projects with an audience in Russia and the CIS, and for systems where local availability, a Russian-language ecosystem and data localization requirements are important. It works particularly well in combination with other Yandex Cloud services. But, like any CAPTCHA, it does not by itself close the whole class of attacks and does not replace rate limiting, WAF and server-side anti-fraud logic.

6. Summary table

7. Minimal production checklist

Before considering CAPTCHA “implemented”, check:

• the token is validated only on the server;
• the secret key is not exposed anywhere in frontend code;
• a timeout is set on the request to the CAPTCHA API;
• token reuse is not allowed;
• validation errors are logged;
• there is separate logic for fallback when the external CAPTCHA API degrades;
• the score threshold for invisible solutions is tuned on real traffic;
• CSP is configured and does not break widget loading;
• CAPTCHA is complemented by rate limiting and basic anti-fraud logic.

Conclusion

If you choose pragmatically, without religious wars and excess theory, for most modern web applications Cloudflare Turnstile currently looks like the most universal option: fast, unobtrusive for users, formally well thought-out for accessibility and not tied to the Google ecosystem.

If data localization, availability from Russia and integration with Yandex Cloud are critical, Yandex SmartCaptcha is a very strong candidate. Just don’t sell it as an “automatic guarantee of compliance with 152-FZ”: it’s more correct to say it fits well into an infrastructure built with those requirements in mind.

If you need a more advanced fraud protection model with risk assessment and tight integration with the Google ecosystem, consider reCAPTCHA Enterprise. If you want a privacy-first alternative with a strong enterprise level without Google — consider hCaptcha.

And the main point: CAPTCHA is not a silver bullet. It should be part of a broader protection model, not the only barrier between your API and a bot farm.