Turnstile, reCAPTCHA and hCaptcha issue verification tokens that the application must validate on the server. The right choice depends on integration, visitor friction, privacy and how your team handles failed checks. None replaces rate limiting or lead-quality review.
The decision is bigger than the widget
A contact form can attract a hundred automated submissions and still lose a genuine buyer if its protection is difficult to complete. The goal is to stop abusive requests while leaving a clear path for legitimate visitors, including people using assistive technology or slower connections.
We reviewed the public integration documentation on October 30, 2026. This is not a controlled fraud-detection benchmark. We have not measured accessibility, conversion, pricing or attack-detection performance across the three services.
| Buyer question | Cloudflare Turnstile | Google reCAPTCHA | hCaptcha |
|---|---|---|---|
| Core integration | Widget issues a token; server calls Siteverify | Client issues a response token; server verifies it | Widget issues a token; server posts it to Siteverify |
| Token handling | Cloudflare documents single-use tokens valid for five minutes | Google’s verification guide says single-use tokens expire after two minutes | hCaptcha documents single-use tokens and a short verification window |
| Request format | Siteverify accepts JSON or form-encoded requests | Verification guide documents a POST with secret and token | Siteverify expects URL-encoded form POST, not JSON |
| What to establish | Widget mode, action/hostname checks and failure handling | Exact product version, challenge behaviour and contract | Sitekey configuration, challenge experience and product tier |
Sources: Cloudflare validation, Google verification guide, and hCaptcha developer guide. Product features and terms vary by configuration; ask each provider about the exact version being purchased.
Cloudflare Turnstile: verify before saving
Cloudflare’s documentation says the widget alone is not enough: the application must send the token to its Siteverify endpoint. It documents a five-minute lifetime and rejects a token that has already been validated. For a long application form, that matters. Someone may start the form, research a question and come back after the token expires.
Design the flow so that the user can obtain a fresh token without losing the information they already entered. Verify the response on the backend before sending a notification or saving the enquiry. Check the hostname and action where your integration uses them. A browser-side success message should never be the only gate.
Google reCAPTCHA: confirm the exact product
Google offers different reCAPTCHA products and integration approaches. The cited verification guide describes a response token that is verified server-side and expires after two minutes. That guide should not be treated as a complete specification for every product or version.
Ask the provider which version, risk signals and decision process apply to your implementation. If you use a risk score, agree who sets the threshold and how the team will review false positives. A score is a decision input, not a guarantee that an enquiry is genuine.
hCaptcha: pay attention to the request format
hCaptcha’s developer guide specifies a form-encoded POST containing the secret and response token. It says JSON is not the expected request format. A syntactically successful form submission on the front end does not prove the server has checked the token.
Test invalid, expired and already-used tokens in a non-production environment. Keep the secret on the server and check which capabilities belong to the proposed account tier. Where the provider returns a hostname or other context, determine how your application will verify it.
Compare the complete lead journey
Run the same test cases for each candidate: a normal visitor, a user who takes several minutes, an interrupted mobile connection, a rejected token and a verification service outage. Include a keyboard-only test and testing with assistive technology. Record what the visitor sees and whether their entered information remains available after a retry.
Measure form starts, completed verification, accepted submissions and qualified enquiries separately. If accepted enquiries fall after deployment, investigate before tightening the rules. Keep an email option for visitors who cannot complete the form, and apply appropriate spam handling to that channel too.
Rate limits, validation of form fields and review of suspicious content are separate layers. Bot controls should not be presented as proof that a contact is authentic, and restrictions on a form endpoint should not be confused with rules governing search-engine access to public pages.
Sources and next steps
Check the current provider documentation and privacy terms before implementation. For project planning, explore security and audit vendors and identity providers. These are adjacent categories, not substitutes for a bot-protection integration.
FAQ
Does displaying a challenge protect an API endpoint?
Not by itself. The server must validate the token and apply the decision before accepting the protected action.
Should a failed challenge always mean a permanent block?
Not necessarily. Distinguish an invalid token from a temporary verification outage and offer a clear retry or alternate contact path appropriate to your risk model.
Does blocking spam form submissions mean blocking search crawlers?
No. Form submissions and public-page crawling are separate flows. Evaluate access controls carefully and verify crawler behaviour independently.
Planning a secure onboarding flow?
Tell us about your project or email contact@fluidrwa.com.