Modern consent managers — Cookiebot, OneTrust, Complianz,
Borlabs, CookieYes, and the rest — work by sitting in
front of your other scripts and refusing to let them
execute until the visitor has made a choice. That is the
whole point: under the GDPR and the ePrivacy regime,
most non-essential third-party scripts are supposed to
wait for prior consent rather than firing on
page load. The trouble is that these tools cannot read
your mind about why a script is on the page.
To a consent scanner, Google's
recaptcha/api.js looks like just another
Google script to be gated alongside Analytics and Ads —
so it gets blocked, deferred, or stripped, and the
widget it was supposed to render never appears.
The result is a particularly nasty failure pattern. For
the developer testing the site, everything works,
because they clicked "Accept All" once and the browser
remembered it. For a brand-new visitor who declines
cookies — or for anyone in a fresh incognito window —
the reCAPTCHA box is blank, the
g-recaptcha-response field stays empty, and
the form either silently fails or throws a server-side
"missing CAPTCHA token" error. The bug only exists for
the exact users you cannot see in your own session,
which is why it so often ships to production unnoticed.
The Real Question: Does reCAPTCHA Even Need Consent?
This is where the engineering fix and the legal question meet, and where you should not guess. Many security and anti-fraud tools are argued to fall under a "strictly necessary" or "legitimate interest" basis — the form genuinely cannot function safely without the verification step — which is a different footing from analytics or advertising scripts that exist to track users. European data protection authorities have not issued one universal blanket ruling that settles every CAPTCHA case, and the answer depends on what the widget does, what data it sends, and the legal basis your organization documents. Treat the categorization of your CAPTCHA as a decision to make with whoever owns your privacy posture, not a checkbox to flip on instinct.
That decision drives everything technical that follows. If the verification script is classified as strictly necessary for the security of the form, your consent manager should be configured to let it load before the consent choice — the same way it would never gate the script that runs the login itself. If instead it is treated as requiring consent, then you must accept that the protected form simply will not be submittable for visitors who decline, and you need to design for that reality rather than ship a dead button. Note that reCAPTCHA's own terms have historically required that sites disclose its use and Google's data practices to users, which is one reason a visible notice — separate from the cookie banner — belongs in your flow regardless.
What "strictly necessary" buys you technically
When a script is marked necessary, most consent
platforms expose an allowlist or a category override so
the tag is excluded from blocking. In Complianz and
similar WordPress plugins this is a "no blocking" or
"exclude this script" setting; in Cookiebot it is the
manual cookie-declaration category and the
data-cookieconsent="ignore" attribute on the
script tag; in tag-manager-driven setups it is a
consent-mode configuration that lets security tags fire
without a granted analytics signal. The mechanics differ
per vendor, but the goal is identical: tell the consent
layer "this one is infrastructure, not tracking — let it
run."
The Load-After-Consent Pattern (When You Must Gate It)
If your privacy decision is that the widget should only
load after consent, do not leave a permanently dead
form. Load reCAPTCHA on demand the moment
consent is granted, and degrade gracefully before then.
The cleanest approach is to not place the
<script> tag in your markup at all, and
instead inject it from the consent manager's
"consent granted" callback:
// Pseudocode — run from your CMP's "statistics/marketing granted" event
function loadRecaptcha() {
if (document.getElementById('recaptcha-script')) return;
var s = document.createElement('script');
s.id = 'recaptcha-script';
s.src = 'https://www.google.com/recaptcha/api.js?render=YOUR_SITE_KEY';
s.async = true; s.defer = true;
document.head.appendChild(s);
}
// e.g. window.addEventListener('CookiebotOnAccept', loadRecaptcha);
Pair that with an honest fallback. Until the script loads, the submit button should show a short message — "Accept cookies to enable spam protection on this form" — rather than appearing functional and then failing. This keeps the user informed instead of blaming them for a silent error, the same principle we apply to the wider family of CAPTCHA loops and stuck states.
Don't Confuse This With a CSP or Network Block
A consent-blocked widget looks superficially identical to
several other failures, so confirm you are chasing the
right one. If the script is blocked by a
Content-Security-Policy, the console shows a "Refused to
load" violation naming a directive — that is the subject
of our
CSP and CAPTCHA guide, not this one. If the script is blocked by an ad
blocker, privacy extension, or an unreachable endpoint,
the failure follows the
script-loading and browser-error
pattern. The tell for a consent conflict specifically is
timing: the widget works after you click "Accept" and
fails for fresh or declining visitors. Test in a clean
incognito window, decline cookies, and watch whether
api.js ever appears in the network tab. If
it never requests, your consent manager is the culprit.
A Verification Layer That Asks for Less Consent Surface
Part of why this problem is so common is that classic reCAPTCHA pulls in a third-party Google script and the data-handling questions that come with it, which is precisely the kind of dependency consent managers exist to gate. A verification approach like rCAPTCHA that leans on first-party behavioral signals keeps the external footprint — and therefore the consent surface — smaller, which can simplify the categorization conversation. It does not erase your obligations: any externally loaded verification, ours included, still belongs in your privacy disclosures and your consent configuration explicitly rather than slipping through under a wildcard. The point is that fewer third-party hooks means fewer places for a consent banner to silently break your forms. For the broader trade-offs, our GDPR and CAPTCHA privacy overview covers the policy side in depth.
People Also Ask: Consent Banners and reCAPTCHA
Why does reCAPTCHA work for me but not my visitors?
Almost always because you have already accepted cookies and your consent manager remembers it, while new or declining visitors have the reCAPTCHA script blocked. Reproduce it in a fresh incognito window and decline the banner.
Can I exclude reCAPTCHA from my cookie banner?
Most consent platforms let you mark a script as strictly necessary or add it to an allowlist so it is not blocked. Whether you should depends on how your organization classifies the CAPTCHA's legal basis — a decision to make with your privacy owner, not purely a technical toggle.
Does using reCAPTCHA require a cookie consent notice?
reCAPTCHA's terms have required sites to disclose its use and Google's data practices, so a clear notice in your flow is expected regardless of how you categorize the script in your consent manager. The exact wording and legal basis should be reviewed by whoever owns your compliance.
How do I load reCAPTCHA only after consent?
Remove the static script tag and inject
api.js from your consent manager's
"consent granted" callback, and show a clear placeholder
message on the submit control until it loads, so the form
never appears functional while it is disabled.
Conclusion
The cookie-banner-versus-CAPTCHA conflict is not a bug in either tool — it is two correct behaviors colliding. The consent manager is gating third-party scripts as designed; reCAPTCHA needs to load to protect your form. The fix is a deliberate decision rather than a guess: classify the verification script honestly with your privacy owner, then either allowlist it as necessary or load it on consent with an honest fallback — never leave a button that looks alive and isn't. And because every third-party script you gate is one more place this can break, a smaller external footprint is the quietest long-term fix of all. Test it the way your visitors experience it: a clean window, cookies declined, and your eyes on the network tab.
Sources & Further Reading
- Google for Developers: reCAPTCHA FAQ — script loading and disclosure requirements
- Cookiebot support: handling Google reCAPTCHA under prior consent
- Complianz: reCAPTCHA and the GDPR (consent classification)
- GDPR.eu: cookie consent and the prior-consent rule
- WordPress support: reCAPTCHA blocked by consent plugins (discovery signal)