Google reCAPTCHA analyses user behaviour for bot detection and loads resources from Google (USA), often as soon as the form loads.
reCAPTCHA is a special case because the purpose — protection against spam and bot abuse — can in principle be based on a legitimate interest under Art. 6 (1)(f) GDPR. But that changes nothing about § 25 TDDDG: as soon as reCAPTCHA v2/v3 loads scripts from Google and sets or reads identifiers that go beyond what is technically necessary, access to the device requires consent. Case law is still inconsistent here; the conservative line is to include reCAPTCHA in the consent.
The practical compromise many operators use: load reCAPTCHA only on the pages that actually contain a form (contact, login, registration), and not globally via the template. This limits the data transfer to the cases where it serves a concrete protective purpose and makes the balancing test more robust. reCAPTCHA v3, which runs on all pages to build a score, is considerably harder to justify in data protection terms.
There are more data-minimising alternatives that avoid the Google transfer entirely: hCaptcha (EU hosting option), Cloudflare Turnstile (no visible captcha, no cookies), Friendly Captcha (hosted in Germany) or — for simple forms — a server-side honeypot plus rate limiting. For many small websites the last variant is enough and works without any third-party transfer.
Protection against spam can be a legitimate interest (Art. 6 (1)(f) GDPR). However, if reCAPTCHA sets non-necessary identifiers or loads on all pages, § 25 TDDDG comes into play. The US transfer must be justified.
The free scan checks the delivered HTML and shows which services are embedded, whether a cookie banner is detected and whether privacy-policy and legal-notice links are present — with context for each finding. It is not a substitute for legal advice.
This text is general information to the best of our knowledge, not legal advice. For an individual case, consult a law firm specialising in IT law.