Is hCaptcha GDPR-Compliant? What Website Owners Need to Know

hCaptcha can be part of a GDPR-compliant setup, but it does not arrive compliant out of the box, and it takes more governance work than many website owners expect.

Intuition Machines, the US company behind hCaptcha, offers a data processing agreement, EU–US Data Privacy Framework certification, and standard contractual clauses. Those are real tools, and they matter. But they do not do the compliance work for you. Legal basis, cookies, international data transfers, and accessibility all still need to be sorted at your end, before you go live, not after a supervisory authority comes knocking.

This article walks through exactly where those questions arise, what they mean in practice, and what a defensible setup actually looks like.

Editorial note: This article is for informational purposes and does not constitute legal advice. For questions about your specific implementation or applicable national law, please consult a qualified privacy or legal professional.

---

---

At a glance: the four GDPR questions hCaptcha raises

Before diving into the detail, here is a quick map of the key issues. Each one is explained fully below.

GDPR question	hCaptcha’s position	What you as the operator must still do
International data transfer	DPF-certified; SCCs available in DPA	Verify the DPA is signed; document your transfer assessment
Cookies and ePrivacy	Sets cookies including hmt_id	Assess whether the technical necessity exemption applies in your jurisdiction
Role (processor or controller)	Acts as processor per its FAQ	You remain the controller. Lawful basis, transparency and vendor oversight stay with you.
Accessibility	Targets WCAG 2.2 AA; some visual challenges remain partially inaccessible	Test the real user flow. Do not rely on the vendor’s statement alone

---

How hCaptcha actually works

When someone submits a form on your website, hCaptcha steps in to decide: is this a human or a bot? Depending on your plan, it either shows a visible challenge (the familiar “pick all the traffic lights” task), uses invisible background signals or applies a mix of both. If the check passes, it hands the form a token. Your server then verifies that token with hCaptcha’s API.

To run that analysis, hCaptcha processes technical and behavioural data. Its privacy policy lists communications metadata such as the originating IP address, along with analytics information including browser type, ISP, platform, device type, operating system and access timestamps. It also sets cookies, including htm_id described as a first-party cookie used for strictly necessary, anonymous, service-related statistics and technical functions including accessibility support.

That data processing, the IP addresses, the browser signals, the cookies, is where the GDPR questions begin.

---

Why this matters more than it might seem

Is it easy to treat CAPTCHA as a small technical detail? It is not. CAPTCHA sits at the front door of the most sensitive workflows on your website: login, password reset, registration, checkout, and contact forms. These are exactly the flows attackers target first.

Credential stuffing, where automated tools test millions of stolen username and password combinations, hits login forms specifically. Fake account creation, card testing, and form spam hit the others. ENISA’s threat landscape reports consistently rank automated abuse of web-facing applications among the most common attack types affecting European organisations.

That makes choosing a CAPTCHA both a security decision and a data-protection decision. A tool that reduces bot risk but creates legal exposure, through unresolved cookie consent, unclear transfer basis, or accessibility gaps, solves one problem while quietly creating another. For IT managers, developers, and DPOs, it is worth treating those two sides of the question together.

---

The three GDPR risk areas, explained

1. International data transfer

Intuition Machines is a US company. Its privacy policy states that it may process personal data of covered individuals in the United States as part of providing the service. It is also certified under the EU–US Data Privacy Framework.

DPF certification is a legitimate and meaningful transfer tool, but it is not a blank cheque. The EDPB’s guidance makes clear that organisations must verify the mechanism is in place and in scope. It must not simply assume that certification covers every scenario. A useful reference point is the Austrian Data Protection Authority’s 2022 ruling on Google Analytics (GZ: 2021-0.586.257). Which found that transmitting IP addresses and browser identifiers to a US server constitutes a transfer of personal data. While that ruling concerned Google Analytics specifically, it illustrates how strictly EU supervisory authorities may scrutinise transfers of technical metadata to US-based providers and why the analysis cannot be skipped simply because a tool holds DPF certification.

In practical terms: sign the DPA, confirm that DPF certification is current and document your transfer assessment in writing. Do not assume that because a vendor has ticked the DPF box, the work is done on your side.

2. Cookies and ePrivacy, a separate question that GDPR does not answer

This is the risk area most often missed, and it reliably catches website operators off guard.

GDPR and the ePrivacy Directive are two different instruments. Article 5(3) of the ePrivacy Directive requires consent before placing cookies or accessing information on a user’s device, unless a specific technical necessity exemption applies. The EDPB’s guidelines on cookies make clear that this exemption is narrow. It must be assessed on a use-case-by-use-case basis; it is not a general carve-out for security or anti-bot tools.

hCaptcha sets cookies. Its cookie policy listshtm_id  and describes it as used for technical and service-related purposes. Whether the technical necessity exemption applies to your specific deployment depends on the concrete use case and the position of your national supervisory authority.

Here is the point that catches people: even if your GDPR legal basis is contract performance or legitimate interests, that does not resolve the ePrivacy cookie question. They are independent obligations. Getting one right does not automatically get you the other. If you cannot clearly demonstrate that the exemption applies in your jurisdiction, the operationally cleaner routes are either loading hCaptcha only after explicit consent, or using a cookie-free CAPTCHA that removes the question entirely.

3. Role allocation: what “processor” actually means for you

hCaptcha’s FAQ states that Intuition Machines acts as a processor for its customers in the relevant GDPR context. That framing is helpful, and the DPA reflects it for core service delivery.

But here is what does not change: you are still the controller. You decide which pages carry the CAPTCHA, what legal basis you rely on, how users are informed, and how you handle a data subject request that touches hCaptcha-processed data. The widget is outsourced. The accountability is not.

In practice: your privacy notice should disclose hCaptcha’s processing. Your record of processing activities should list Intuition Machines as a sub-processor, and you should be able to explain to a supervisory authority why you made the deployment choices you made.

---

Does the plan tier change the compliance picture?

Yes and this is the detail most deployments overlook entirely.

On some plan tiers, data use and contractual controls can differ materially. Enterprise customers may be able to negotiate stricter privacy terms than free-tier deployments, including restrictions on how interaction data is used beyond core service delivery.

If your organisation is processing data from users in regulated sectors, like healthcare, finance, public services, the applicable data use terms are worth examining carefully before deployment, not after. Reviewing the current terms for your specific plan and, where necessary, negotiating DPA clauses that reflect your obligations is part of responsible vendor selection under GDPR’s accountability principle.

---

Accessibility: a compliance question, not a footnote

Accessibility tends to be treated as a secondary consideration in CAPTCHA decisions. For many in-scope digital services operating in the EU, it is no longer optional. The European Accessibility Act, which entered force across member states from June 2025, means that covered businesses and services must meet accessibility requirements, with WCAG 2.2 AA as the relevant technical standard for most web-based implementations.

hCaptcha’s accessibility statement says it targets WCAG 2.2 AA compliance and has carried out internal and external audits. It also acknowledges, honestly, that some visual image challenges cannot be made fully accessible while still performing their security function.

That gap has real consequences. A vendor-level accessibility statement does not make your specific deployment accessible. The following areas require genuine testing in the real user flow, not a check against a PDF from the vendor:

• Keyboard navigation. Can the widget be activated and completed without a mouse? This needs to work for every user.
• Screen reader and audio challenge compatibility. The audio challenge and fallback experience should be tested across screen readers and browser combinations before you rely on it as an accessibility path. Behaviour can vary significantly between NVDA, JAWS, and VoiceOver, and across different browsers.
• Error state handling. When a challenge fails or times out, are error messages announced to assistive technology, or do they appear visually only?
• Mobile behaviour. Does the widget render and function correctly in a mobile browser with system accessibility features enabled?

For public-sector organisations and services with a broad user base, these tests are not optional extras. They are part of what compliance actually requires.

---

How to reduce GDPR risk if you continue using hCaptcha

If you have worked through the above and decided hCaptcha is the right tool for your context, the following steps will put you in a materially stronger position.

---

Conclusion

hCaptcha is not automatically unlawful in Europe. For organisations prepared to do the governance work, signed DPA, transfer documentation, ePrivacy cookie assessment, plan-tier review and real accessibility testing, it can be part of a compliant deployment.

The honest answer, if hCaptcha is GDPR-compliant, is: it depends on how you deploy it, what plan tier you are on, which sector you operate in, and how thoroughly you have documented your decisions. Vendor certification is a starting point, not a finishing line.

For some organizations, that trade-off may still be acceptable. However, others may prefer a European CAPTCHA solution that reduces privacy friction and avoids visual challenge barriers. In that context, captcha.eu can be a relevant alternative. It is hosted in Austria, designed to be GDPR-compliant, uses no cookies and no tracking, and holds WACA Silver / WCAG 2.2 AA certification.

---

FAQ – Frequently Asked Questions