reCAPTCHA alternatives for contact forms (that don't need Google)

Search "stop contact form spam" and Google reCAPTCHA is the first thing everyone reaches for - it's free, it's a drop-in widget, and the "I'm not a robot" checkbox is familiar enough that nobody questions it. Reasonable defaults deserve a second look occasionally, though, and reCAPTCHA is a good candidate: it's not the only option, and for a lot of sites it isn't the right one.

The real reasons to reconsider it

reCAPTCHA is a third-party Google script, and that has consequences beyond "it works":

• Privacy and consent. reCAPTCHA sets cookies and sends visitor data to Google for its risk scoring. For EU visitors, that raises real GDPR consent questions - a contact form is exactly the kind of low-friction interaction that shouldn't require a cookie banner just to load a spam filter.
• Another render-blocking script. It's one more external request in the critical path of a page whose entire job is to load fast and let someone type a message.
• Friction for real humans. Anyone on a VPN, a privacy browser, or with tracking protection enabled has hit the "select all the traffic lights" challenge more than once. That's a real visitor who almost gave up.
• General reluctance to hand Google another hook into your site. Plenty of developers just don't want every visitor's browser talking to Google before they can send a message - a defensible position on its own, independent of the privacy specifics.

Alternative 1: the invisible honeypot field

A hidden input that real visitors never see and never fill in, but that unsophisticated bots dutifully complete because it's sitting right there in the markup. If it arrives non-empty, the submission is spam - discard it, no challenge shown to anyone. Zero third-party script, zero friction, and it quietly catches the overwhelming majority of form spam, which is dumb crawlers rather than anything clever. (Full implementation details, including the exact markup and accessibility gotchas, are in our spam-protection deep dive.)

Alternative 2: rate limiting

Honeypots don't stop a bot that POSTs valid-looking data hundreds of times a minute - a per-IP and per-form limit at the receiving endpoint does. A real visitor never submits the same contact form ten times in a minute, so nothing of value is lost by throttling, and it requires no widget, no cookie, and no decision from the person filling out the form at all.

Alternative 3: Cloudflare Turnstile, when you actually need a challenge

Sometimes a form draws smarter bots - headless browsers that render CSS and skip the honeypot entirely - and a challenge becomes worth the small conversion cost. Cloudflare Turnstile is the privacy-respecting version of that: it verifies a visitor through browser signals rather than tracking cookies, usually resolves invisibly, and doesn't route the interaction through Google at all. It's the same job reCAPTCHA does, without the parts people object to.

Layer them - and be honest about the limits

No single method here is bot-proof, including Turnstile. The realistic answer is the same one for any form: honeypot first, rate limit underneath it, and a challenge added only when the first two stop being enough - the exact posture we cover in more depth in the spam-protection guide. What changes with this framing is just the default: skip Google's script as the opening move.

It's also the posture Formhook ships with, applied automatically. Every form gets a honeypot field and per-IP/per-form rate limiting on by default, on every tier including Free - no configuration, no widget to install. Turnstile is there as an opt-in checkbox in the form settings for the forms that need the extra layer. See pricing for what's included at each tier.