First, the rule, straight from Google's official reCAPTCHA FAQ: you are allowed to hide the badge, but only if you include the reCAPTCHA branding visibly in the user flow. That means showing this text where users interact with your protected form:
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Hide the badge without that substitute attribution and you are out of compliance with the terms you accepted when you created your keys. WordPress support forums are full of "how do I remove this element?" threads where the badge simply gets nuked with CSS and the disclosure requirement is never mentioned.
The Compliant Recipe
Two steps, in this order:
- Add the attribution text to the form. Place it near the submit button of every form the CAPTCHA protects — small, muted text is fine, as long as it is visible in the flow. It does not need to appear sitewide, only where protection applies.
-
Then hide the badge with visibility, not
display.
.grecaptcha-badge { visibility: hidden; }
Why visibility: hidden and not
display: none? Community testing —
documented in guides like
OOPSpam's badge writeup
and
webdeasy's tutorial
— repeatedly reports that removing the badge from the
layout entirely with display: none can
interfere with the widget's operation, while
visibility: hidden keeps the element in
the DOM and the verification machinery intact. Treat
that as a practical convention with broad consensus:
the visibility approach has no known downside, so
there is no reason to gamble on the riskier property.
A gentler middle ground, popularized in the Experts Exchange walkthrough, is to keep the badge but pull it off-screen except on hover or focus, or to reduce its opacity — useful when legal wants the badge technically present but design wants it out of the way. The same attribution rule still applies the moment the badge is not plainly visible.
What People Get Wrong
- Hiding the badge but skipping the text. The most common state in the wild. It works technically and fails contractually — an audit or a competitor's report away from a problem.
- Using display:none "because it worked in staging." Verification failures from an unloaded or broken widget surface as forms that silently stop submitting — the same symptom family as the score and token problems in our v3 low-score guide.
- Z-index wars instead of hiding. Stacking the chat widget on top of the badge leaves both half-clickable on mobile. If the badge has to share a corner with anything, hide it compliantly instead of layering over it.
- Forgetting v2 invisible. The invisible v2 variant renders the same badge and follows the same FAQ rule; checkbox v2 shows its branding inside the checkbox widget itself, which is why it has no badge to hide.
Where the Attribution Text Should Live
"Visibly in the user flow" is the load-bearing phrase in Google's FAQ, and it is worth being concrete about what satisfies it in real layouts:
- Classic forms: a small muted line directly below the submit button. Users glance at it exactly when verification happens, which is the intent of the rule.
- Multi-step checkouts and wizards: put the text on the step where the protected action fires — usually the final "Place order" or "Create account" screen — not buried on step one.
- Single-page apps: if reCAPTCHA executes on route-level actions (login modal, comment box), render the attribution inside those components so it travels with the protection rather than living on a page the user may never scroll to.
- Sitewide footers: a common belt-and-suspenders addition, and useful when v3 runs on every page — but if the footer is the only disclosure and your protected form sits in a modal three viewports away, you are leaning on a technicality. Put it near the action too.
Keep the links in the text pointing at Google's actual Privacy Policy and Terms of Service pages — the disclosure exists because user interaction data flows to Google for scoring, and that data flow is also why the badge interacts with your own privacy policy and, for European audiences, your GDPR disclosures. Hiding the badge does not hide the processing; your privacy page should mention reCAPTCHA whether or not the corner logo shows.
The Bigger Question the Badge Raises
Step back and the badge fight is a symptom of a design tension: invisible verification still wants to be seen. The badge exists because users are being scored in the background and Google requires disclosure of that fact; site owners hide it because a permanent vendor logo in the conversion path is UX and brand noise. Both sides are right, which is why the compromise — hidden badge, visible one-line disclosure — became the standard pattern.
When you evaluate any verification provider, it is worth asking what the disclosure story is up front: what must be displayed, where, and what happens to your protection if a designer hides it. Lightweight behavioral systems such as rCAPTCHA aim to keep the user-facing footprint minimal so there is less chrome to fight over — and whatever provider you choose, the cost of verification UI belongs in the same conversation as its accuracy, alongside the broader friction trade-offs we cover in CAPTCHA vs. user experience.
People Also Ask: reCAPTCHA Badge FAQ
Is it legal to hide the reCAPTCHA badge?
Yes, Google's FAQ explicitly allows it — on the condition that you include the "This site is protected by reCAPTCHA…" text, with links to Google's Privacy Policy and Terms of Service, visibly in the user flow of the protected form. Hiding the badge without that text violates the terms.
What CSS hides the reCAPTCHA badge safely?
Use
.grecaptcha-badge { visibility: hidden; }.
Community testing widely reports that
display: none can interfere with
verification, so the visibility approach is the
accepted safe pattern.
Does the attribution text need to be on every page?
No — it needs to be visible in the user flow where reCAPTCHA protection applies, which in practice means on or near the protected forms. A sitewide footer notice is a common belt-and-suspenders choice but is not required by the FAQ.
Why does the badge overlap my chat widget?
Both default to fixed positioning in the bottom-right
corner. Rather than fighting with z-index, hide the
badge compliantly and let the chat widget own the
corner — or configure the badge inline
(data-badge="inline" for invisible v2)
and place it inside the form layout.
Conclusion
Hiding the reCAPTCHA badge is a two-line job that most
sites do half of. The CSS is trivial; the compliance
half — the visible attribution text in the form flow —
is the part that keeps you inside Google's terms.
Use visibility: hidden, add the
disclosure next to your submit button, leave
display: none alone, and treat the whole
exercise as a reminder that verification UI is part of
your conversion path, not an accessory bolted onto its
corner.
Sources & Further Reading
- Google for Developers: reCAPTCHA FAQ (badge hiding and branding requirements)
- WordPress.org support: "Protected by reCAPTCHA – how to remove this element?"
- Experts Exchange: removing the v3 badge without breaking the rules
- OOPSpam: How to hide the reCAPTCHA badge
- webdeasy: How to remove the reCAPTCHA badge from your website