GDPR & CAPTCHA: What Developers Actually Need to Do

GDPR doesn't ban CAPTCHAs. But most CAPTCHA implementations violate it — and the developer who embedded the widget is liable, not the CAPTCHA vendor. France's CNIL has already fined companies for using reCAPTCHA without valid consent. Bavaria's BayLDA has specifically cautioned against US-based CAPTCHA services.

Why CAPTCHAs Trigger GDPR

GDPR applies whenever you process personal data of EU residents. Every major CAPTCHA service processes:

• IP addresses — personal data under GDPR (CJEU ruling, Breyer v. Germany)
• Browser fingerprints — device type, screen resolution, installed fonts, WebGL renderer
• Behavioral data — mouse movements, keystroke timing, scroll patterns
• Cookies — hCaptcha and reCAPTCHA set tracking cookies; Turnstile claims not to

This data is collected before the user even submits the form. The CAPTCHA JavaScript loads on page render and starts processing immediately.

The April 2026 reCAPTCHA Change

On April 2, 2026, Google shifted reCAPTCHA's legal role from data controller to data processor. This means:

• Before: Google determined how reCAPTCHA data was used. Google's privacy policy covered it.
• After: You, the site operator, are the data controller. You're legally responsible for how the data is processed, stored, and shared.

Action required: Update your privacy policy. Remove references to Google handling reCAPTCHA data. Add your own disclosures about what data is collected and why. Sign Google's Data Processing Addendum if you haven't already.

The Three Legal Requirements

1. Lawful Basis (GDPR Article 6)

You need a legal justification for processing this data. Two options apply to CAPTCHAs:

Legitimate interest: You argue that protecting your forms from spam is a legitimate business need that outweighs the user's privacy rights. This is the most common basis for CAPTCHAs, but it requires a documented Legitimate Interest Assessment (LIA) — not just a mental note.

Consent: You ask the user for explicit permission before loading the CAPTCHA. This is legally safer but creates a UX problem: you need a consent banner, and users who decline can't submit your form.

Which to use: For security-critical forms (login, registration), legitimate interest is defensible — protecting against brute force attacks is clearly necessary. For marketing forms (newsletter signups, contact forms), the case is weaker. A DPA may argue that a honeypot provides adequate protection without processing personal data.

2. Cookie Consent (ePrivacy Directive)

Separate from GDPR, the ePrivacy Directive requires consent before setting non-essential cookies. In Germany (TTDSG), the UK (PECR), and France (CNIL guidance), this means:

• reCAPTCHA: Sets cookies. Requires prior consent. The Austrian DPA ruled that reCAPTCHA cookies are not "technically necessary."
• hCaptcha: Sets cookies. Same consent requirement applies.
• Turnstile: Claims not to set cookies, but still processes IP and browser data. Whether this triggers consent requirements depends on your DPA's interpretation — err on the side of caution for EU-facing forms.
• ALTCHA / Friendly Captcha: No cookies, no personal data transfer (when self-hosted). No consent needed.

3. Data Transfer Rules (Schrems II)

If the CAPTCHA service sends EU user data to US servers, you need a valid transfer mechanism:

The EU-US Data Privacy Framework (DPF) is the current legal basis for US transfers, but it faces potential "Schrems III" challenges. If it's struck down — as Safe Harbor and Privacy Shield were before it — sites relying on DPF will need to scramble for alternatives or stop using US-based services.

Compliance Checklist for PHP Developers

If you're using any third-party CAPTCHA service with EU users:

1. Choose your lawful basis and document it. If using legitimate interest, write a Legitimate Interest Assessment covering what data is processed, why it's necessary, and why less-invasive alternatives (honeypots) aren't sufficient.
2. Update your privacy policy to disclose the CAPTCHA service, what data it collects, the lawful basis, and transfer mechanisms for US-based services.
3. Implement cookie consent if the CAPTCHA sets cookies. Load the CAPTCHA JavaScript only after consent is given — don't load it by default and ask forgiveness later.
4. Sign a Data Processing Agreement (DPA) with the CAPTCHA provider. Google, Cloudflare, and hCaptcha all offer these.
5. Consider a Transfer Impact Assessment (TIA) for US-based services. Document why the transfer is necessary and what supplementary measures protect the data.
6. Provide a fallback for users who decline consent. This could be an alternative verification method or accepting the submission with additional server-side checks.

The Consent-Loading Pattern in PHP

If you need consent before loading a CAPTCHA, here's the pattern:

<?php
// Simplified example — in production, integrate with your Consent Management Platform (CMP)
// A simple cookie check is insufficient for GDPR proof-of-consent requirements
// You must log consent timestamps and be able to demonstrate consent was obtained
// Load CAPTCHA only after consent — server-side rendering approach
$captchaConsent = isset($_COOKIE['captcha_consent']) && $_COOKIE['captcha_consent'] === 'yes';
?>

<form method="POST" action="/submit.php">
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>

  <?php if ($captchaConsent): ?>
    <!-- User consented — load Turnstile -->
    <script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>
    <div class="cf-turnstile" data-sitekey="YOUR_SITE_KEY"></div>
  <?php else: ?>
    <!-- No consent — fall back to server-side checks only -->
    <p><small>Enable cookies to use automatic verification,
    or your submission will be reviewed manually.</small></p>
  <?php endif; ?>

  <button type="submit">Send</button>
</form>

<?php
// Server-side handler — different validation paths based on consent
$captchaConsent = isset($_COOKIE['captcha_consent']) && $_COOKIE['captcha_consent'] === 'yes';

if ($captchaConsent) {
    // Consent given — verify CAPTCHA token
    $valid = verifyTurnstile($_POST['cf-turnstile-response'] ?? '', getenv('TURNSTILE_SECRET') ?: '');
    if (!$valid) {
        $errors[] = 'Verification failed.';
    }
} else {
    // No consent — rely on honeypot + timing + rate limiting only
    if (checkHoneypot($_POST)) {
        $errors[] = 'Submission blocked.';
    }
    if (!verifyTiming($_POST['_ts'] ?? '')) {
        $errors[] = 'Please try submitting again.';
    }
    // Flag for manual review
    $needsReview = true;
}

The Path of Least Resistance

If GDPR compliance feels like too much overhead for a CAPTCHA, consider solutions that avoid the problem entirely:

• ALTCHA (self-hosted): Open-source proof-of-work. No personal data leaves your server. No cookies. No consent needed. No DPA required. See our PHP CAPTCHA code examples.
• Friendly Captcha: EU-hosted (Germany), no cookies, WCAG 2.2 certified. Paid service but eliminates transatlantic data transfer issues.
• Honeypot + rate limiting: No personal data processing beyond what your server already handles. Fully compliant by default. See our PHP form spam protection guide.

Verdict

GDPR compliance with CAPTCHAs is achievable but requires work. If you're using reCAPTCHA, hCaptcha, or Turnstile for EU users, you need documented lawful basis, privacy policy updates, consent management for cookies, and signed DPAs. Most PHP developers haven't done these steps — which means most PHP sites using these services are technically non-compliant.

The pragmatic path: use ALTCHA or Friendly Captcha for EU-facing forms and eliminate the compliance burden. Use Turnstile or hCaptcha for non-EU traffic where GDPR doesn't apply. And regardless of which CAPTCHA you use, layer it with honeypots and rate limiting so the CAPTCHA isn't doing all the work.

The simplest path to GDPR compliance isn't adding paperwork to a US-based widget — it's choosing tools that don't create a privacy problem in the first place.