Is Google reCAPTCHA GDPR compliant? Not out of the box

No, not out of the box. Google reCAPTCHA loads its code from google.com and gstatic.com, sets a cookie in the visitor's browser and sends the signals it collects to Google. Under the ePrivacy rules (§ 25 TDDDG in Germany) storing information on the visitor's device, or reading it from there, needs consent unless an exception applies, most often that it is strictly necessary for a service the visitor asked for. Whether a third-party risk-analysis cookie clears that bar depends on your implementation, and it is a judgement you make as the site operator, not one Google can make for you. If you decide it needs consent, every protected form is unusable until the visitor clicks accept.

The fix is not a better banner. It is a CAPTCHA that stores nothing on the device and reads as little from it as the check needs.

Why Google's FAQ says something different

Google's own reCAPTCHA FAQ says it commits in its Cloud Data Processing Addendum to comply with the GDPR, and since 2 April 2026 Google acts as a processor for reCAPTCHA data rather than an independent controller. That change matters: you now have a processing contract instead of a hand-over to a second controller, and the requirement to show Google's Privacy Policy and Terms in the badge is gone.

What it does not change is the part that happens before any of that: the script still runs in the visitor's browser, and the same FAQ states that reCAPTCHA "sets a necessary cookie (_GRECAPTCHA)" for its risk analysis. Google calling a cookie necessary describes Google's view of its own product. The ePrivacy question is yours as the controller, and so is the record of processing, the privacy notice and the transfer assessment for a US provider.

What reCAPTCHA does the moment it loads

We fetched it on 12 October 2026. The api.js loader from google.com is only 976 bytes, but its job is to pull the real bundle from gstatic.com: 850,545 bytes, 353,584 gzipped for the English build. That bundle references localStorage and sessionStorage and more than a dozen google.com hostnames. Before the visitor has typed a character, two Google domains have seen their IP address, their User-Agent and, depending on your referrer policy, the page they are on.

For comparison, Bollwark's widget is four files from one origin: the script, its stylesheet, a Web Worker and the Argon2 hash library. Together they are 99,802 bytes, 34,258 gzipped, and none of them touches document.cookie, localStorage, sessionStorage or IndexedDB. Sizes are our own curl measurements; your browser may receive brotli, so the wire size will differ.

Why "just add a consent banner" breaks the form

Consent banners were designed for analytics: if someone declines, you lose a data point and the page keeps working. A CAPTCHA is different, because it sits in front of something the visitor is trying to do.

If reCAPTCHA only loads after consent, you have three outcomes, and none of them is good:

• The visitor accepts. The form works, and you have traded a signup for a cookie consent you did not otherwise need.
• The visitor declines. Either the form refuses to submit, and you have locked out a real person for exercising a right the law gives them, or it submits without a check, and the bots that never click "accept" walk straight through.
• The visitor ignores the banner. Same as declining, except they do not know why the button does nothing.

A common workaround is a placeholder that loads reCAPTCHA only when the visitor clicks into the form (Händlerbund describes the pattern). It is better than a page-wide banner, but it is still one more click and one more sentence of legal text between a person and your signup.

What a CAPTCHA has to do to keep the question small

You cannot make the ePrivacy question disappear by avoiding cookies alone: Article 5(3) of the ePrivacy Directive covers reading information from the device as well as storing it, which the EDPB spells out in its Guidelines 2/2023 on the technical scope of Article 5(3). What you can do is keep the access minimal and clearly tied to the security check. In practice that means:

1. Nothing stored on the device, and only the reads the check needs. No cookie, no local storage, no fingerprinting, so the remaining access can be argued as strictly necessary for the protection the site provides.
2. No third party in the request path, or at least one inside the EU under a processing contract.
3. Minimised network data. Truncate the IP address before it is written down, and delete what you keep on a short schedule.
4. A legitimate-interest basis that fits. Article 6(1)(f) GDPR, with Recital 49 naming network and information security as a legitimate interest.
5. Code you can read, and ideally run yourself, so the data never leaves your servers.

How Bollwark measures against that list

Requirement	Bollwark	What we will not claim
Device storage	None. The widget fetches with credentials: "omit" and the server never issues Set-Cookie.	—
Device access	The widget reads a few browser properties (for example navigator.webdriver and globals that automation tools inject) and counts interactions. Our position, published in the end-user privacy notice, is that this is strictly necessary for the check, so § 25 TDDDG needs no consent.	That this is settled for every setup. Assess it for yours.
Third parties	One script from api.bollwark.eu, or from your own server when you self-host.	—
What the browser sends	Four counters (mouse moves, touches, interactions, time to first interaction) and three booleans (webdriver, automation globals, headless). No mouse paths, no key values, no canvas or WebGL.	That it is anonymous: the IP address and User-Agent still reach the server.
IP address	Used in full, in memory, for scoring; truncated to /24 (IPv4) or /48 (IPv6) before anything is logged.	—
Retention	The decision log is pruned after 72 hours by default. After that a reduced-data record remains: challenge ID, site key, hour, score, tier, difficulty, outcome, signal scores, behaviour counters, network category, country and browser family. No IP address and no User-Agent string.	That nothing personal is stored: the 72-hour log keeps the User-Agent verbatim.
Hosting	Hosted service on Hetzner and Contabo in Germany; no processing outside the EU.	A US region. There is none.
Legal basis	Article 6(1)(f) GDPR and Recital 49, documented in our end-user privacy notice.	That it is GDPR-certified. Bollwark is not.
Source	MIT-licensed Rust, one container (binary plus widget assets). The production binary makes no outbound HTTP calls.	—

Two honest caveats. Bollwark is young: the service is at version 0.1, without a long production track record. And the paid hosted plans are not on sale yet; today you can use the free tier (1,000 verifies a month, one site) or self-host.

Other cookie-free options

You do not have to pick us to avoid cookies:

• ALTCHA is an MIT-licensed proof-of-work widget that says it sets no cookies; its hosted tiers start at €47 a month.
• Friendly Captcha is a German proof-of-work service that advertises zero cookies, with plans from €9 a month; a self-hosted endpoint is Enterprise-only.
• Cloudflare Turnstile is free and usually invisible, but it collects the IP address, TLS fingerprint and User-Agent on Cloudflare's network. We compare it in detail in Turnstile vs reCAPTCHA vs hCaptcha.

If puzzles are the reason you are leaving, see our hCaptcha alternative comparison too.

What to do next

Swapping reCAPTCHA for Bollwark is one script tag and one server call:

<div id="captcha" data-sitekey="<SITE_KEY>"></div>
<script src="https://api.bollwark.eu/v1/widget.js"></script>

Your backend forwards the token to POST /v1/verify with your site secret (integration guide). Start on the free tier, or run the self-hosted, cookie-free CAPTCHA on your own server, where no request ever leaves your infrastructure.

This article describes how the products work. It is not legal advice; your data-protection officer has the last word on your setup.