Forem: Noah Kellner

reCAPTCHA and GDPR: Why Google’s Bot Protection Is a Legal Risk in the EU

Noah Kellner — Thu, 02 Apr 2026 22:21:42 +0000

reCAPTCHA sets cookies, transfers data to the US, and tracks users for ad targeting. Here’s why EU businesses are dropping it — and what to use instead.

The Hidden Cost of “Free” Bot Protection

reCAPTCHA is free. That’s the pitch. But for EU businesses, the real cost is buried in compliance risk.

Google’s reCAPTCHA sets multiple cookies (NID, _GRECAPTCHA), sends user data to US servers, and — per Google’s own Terms of Service — uses reCAPTCHA interactions to improve Google’s ad targeting products.

For any site that needs GDPR compliance, that’s three problems in one script tag.

What reCAPTCHA Actually Does

When a user loads a page with reCAPTCHA, the following happens:

Cookies are set — NID and _GRECAPTCHA are placed in the user’s browser
Data is transferred to the US — Mouse movements, browser fingerprints, IP addresses go to Google servers in the United States
Google processes the data — Per their privacy policy, reCAPTCHA data feeds into Google’s risk analysis systems

This means every site using reCAPTCHA needs:

A cookie consent banner (because reCAPTCHA cookies aren’t “strictly necessary”)
A Data Processing Agreement with Google
A legitimate legal basis for the US data transfer
Disclosure in the privacy policy

The Legal Reality in 2025/2026

Several EU Data Protection Authorities have already flagged reCAPTCHA:

The French CNIL has ruled that reCAPTCHA requires explicit consent because it sets non-essential cookies
Austrian and German DPAs have questioned whether US data transfers meet GDPR standards post-Schrems II
The European Accessibility Act (EAA), effective June 2025, adds another layer: visual CAPTCHA puzzles fail WCAG 2.2 AA standards

The trend is clear: using reCAPTCHA in the EU is becoming harder to justify legally.

What Makes a GDPR-Compliant Alternative?

A bot protection solution that actually works for EU businesses needs to:

Set zero cookies — No consent banner needed for the bot protection itself
Keep data in the EU — No transatlantic transfers, no Schrems II risk
Work invisibly — No visual puzzles that fail accessibility standards
Not track users — Bot protection shouldn’t be a data collection mechanism

Proof-of-Work: The Cookie-Free Approach

Proof-of-Work bot protection flips the model. Instead of tracking users to determine if they’re human, it forces the client to solve a small cryptographic puzzle (SHA-256).

The computation takes ~200ms on a modern device — humans don’t notice it. But bots trying to submit thousands of forms need to solve thousands of puzzles, making spam economically unfeasible.

No cookies. No tracking. No US data transfer. No consent banner needed.

Making the Switch

Replacing reCAPTCHA doesn’t have to be complex. With nForms Shield, the migration is a single script tag:

<!-- Before: reCAPTCHA -->
<script src="https://www.google.com/recaptcha/api.js" async defer></script>
<div class="g-recaptcha" data-sitekey="YOUR_KEY"></div>

<!-- After: nForms Shield -->
<script src="https://api.nforms.eu/shield.js" />

No API key verification on the backend. No cookie consent changes. No privacy policy updates for a new US data processor.

The Bottom Line

reCAPTCHA was designed for a pre-GDPR world where tracking users across the web was the default. In 2026, EU businesses need bot protection that respects the legal framework they operate in.

The question isn’t whether reCAPTCHA works against bots. It does. The question is whether the compliance overhead is worth it when alternatives exist that don’t set cookies, don’t transfer data to the US, and don’t require visual puzzles.

For most EU businesses, the answer is increasingly: no.

I’m building nForms — a form backend with Proof-of-Work bot protection and WCAG 2.2 AA validation. EU-only infrastructure, zero cookies. If you’re dealing with reCAPTCHA compliance headaches, I’d love your feedback.

Why Proof-of-Work Beats CAPTCHA for Form Protection

Noah Kellner — Wed, 01 Apr 2026 10:42:40 +0000

Every developer knows the drill. You add a form to your site, bots find it within hours, and suddenly you're dealing with spam submissions. The traditional answer? CAPTCHA.

But CAPTCHAs come with serious trade-offs:

Conversion killer: Studies show CAPTCHAs reduce form completions by 12–40%
Accessibility nightmare: Visual puzzles are fundamentally inaccessible to screen reader users
Privacy concerns: reCAPTCHA sets cookies and sends data to Google's US servers
User frustration: Nobody enjoys clicking traffic lights

How Proof-of-Work Changes the Game

Proof-of-Work (PoW) flips the model. Instead of asking humans to prove they're human, it asks browsers to solve a small math problem — a SHA-256 hash challenge.

For humans: Completely invisible. The challenge solves in ~200ms in a background WebWorker. Users never see or interact with anything.

For bots: Computationally expensive at scale. A bot trying to submit 10,000 forms needs 10,000 unique PoW solutions. The economics don't work.

The Technical Implementation

Here's how PoW works for form protection (using the ALTCHA wire format):

Browser requests a challenge from the server
Challenge includes a SHA-256 hash target and a maximum number to search
WebWorker iterates through numbers, hashing each with the challenge salt
When a matching hash is found, the solution is attached to the form submission
Server verifies the solution with a single-use nonce (no replay attacks)

The entire process happens in the background. No UI, no interaction, no cookies.

Composite Scoring: Beyond Just PoW

PoW alone isn't enough. A serious implementation should combine multiple signals into a composite score:

PoW verification: Did the browser solve a valid challenge?
Timing analysis: Was the form submitted suspiciously fast?
Honeypot detection: Did a bot fill a hidden field?
AI spam scoring: Does the content look like spam?

Each signal contributes to a final pass/soft-block/reject decision. No single signal is a deal-breaker — and no single bypass breaks the whole system.

What About No-JavaScript Users?

Progressive enhancement matters. If a user has JavaScript disabled:

The form still submits normally
The server flags it as "no-shield" (suspicious but not blocked)
Server-side heuristics (timing, honeypot, AI) still apply
Increased rate limiting provides additional protection

No user is locked out. The protection degrades gracefully.

The GDPR Angle

Unlike reCAPTCHA (which sets NID and _GRECAPTCHA cookies and sends data to the US), a PoW-based approach:

Sets zero cookies
Performs no browser fingerprinting
Stores no personal data
Can run entirely on EU infrastructure

No cookie consent banner needed. No GDPR risk assessment required. The architecture itself is the compliance strategy.

Try It

I built this approach into nForms — a form backend that combines PoW bot protection with WCAG 2.2 AA form validation in a single script tag:

<script src="https://api.nforms.eu/shield.js"></script>

<form data-nforms-key="YOUR_KEY">
  <input name="email" data-validate="required|email" />
  <button type="submit">Send</button>
</form>

Free plan includes Shield Basic (honeypot + timing). The Developer plan (€9/mo for early users) adds full PoW protection.

The contact form on nforms.eu is a live demo — Shield is active on it.

The bottom line: CAPTCHAs were a necessary evil. Proof-of-Work makes them unnecessary. Your forms get protected, your users get a better experience, and your compliance team gets peace of mind.

The future of form protection is invisible.