PrivCaptcha, the modern privacy-first captcha built for GDPR

Three steps, in every implementation. The page loads a widget, the visitor does something the widget can check, and the widget hands back a token. Your server then sends that token to the provider and only accepts the form if the answer comes back valid - the token is the proof, not the puzzle itself. PrivCaptcha follows exactly that shape: our script renders a puzzle, writes the token into a hidden privcaptcha-response field, and your backend verifies it server-side. What differs is the middle step. Most providers decide whether you look human from a profile of you; we score the request itself and use that only to pick how hard the puzzle is.

Every request is challenged - there is no invisible pass to aim a script at, and no allowlist that skips the check. What changes is the form the challenge takes and what it costs. The server scores each request and picks one of five difficulty levels, so an ordinary visitor gets a couple of seconds and a client that looks automated gets tight tolerances and a heavier proof-of-work. On the non-visual path, taken by screen-reader and keyboard visitors, there is no puzzle to solve at all: the proof-of-work is the whole challenge, at a fixed 22 bits.

Because at the moment the request arrives the server has no way to know that. It sees headers and an address, not a person - so most systems guess, and the guess is wrong often enough that real customers get blocked, especially on a VPN, a shared office connection or a privacy browser. PrivCaptcha does not guess at your identity. Everyone gets a puzzle, and the only thing the score changes is how hard it is - so a bad guess costs you a few extra seconds instead of your account.

Not in the sense of making a route unreachable - no captcha does that. Solver farms and automation exist, and anything a person can solve can eventually be solved for money. What a captcha really does is put a price on each attempt, so abuse that only pays at volume stops paying. PrivCaptcha is built around that honestly rather than around a claim of being unbreakable: the puzzle prices the attempt, the proof-of-work prices the scale, and a client that keeps failing pays more each time.

For the classic image grids, largely yes - picking traffic lights out of photographs is the exact task modern vision models are good at, which is why that style of challenge has been getting weaker for years. We do not claim our puzzles are unsolvable by a machine. We assume they are, and make solving them at scale expensive instead: difficulty rises with the risk score and every solve carries a proof-of-work, so the cost curve bends against the attacker even when the puzzle itself is beatable.

Not today, and that is the quiet advantage. The solving services that make bot work cheap sell turnkey support for the big names - you pay per solve and their SDK handles reCAPTCHA or hCaptcha for you, because a captcha on millions of sites is worth building against once and selling forever. Nobody ships a package for us, so an attacker has to write a custom solver, keep it running, and redo that work whenever our challenges change - real engineering time before the first request goes out, and every solve still pays the proof-of-work on top. We would rather be straight about the shape of this: it is an economic advantage, not a mathematical one. If we became the default captcha, solvers would follow. What does not change is the cost curve underneath - difficulty that rises with the risk score, and work priced per solve - which stays expensive at volume whether or not someone has packaged it.

No. An address is used for the length of one request and never written anywhere. What we keep is an HMAC of it under a salt that is random, lives only in Redis and rotates every day, so yesterday's hashes cannot be linked to today's. The counters under that hash expire after 24 hours.

No. Nothing on the widget path touches a Google domain, and the fonts on this site are self-hosted rather than fetched from Google Fonts. That is also why the widget behaves the same on hardened browsers, on privacy browsers and on networks where those services are unreachable.

It depends entirely on what leaves the page. A captcha usually sits on your login and checkout - your most sensitive forms - and most providers send the visitor's IP address and behavioural signals to a third party from there, which is a processing relationship you have to disclose and justify. PrivCaptcha is built to make that section short: we never store a raw IP address, only a truncated HMAC under a salt that rotates daily, with counters that expire after 24 hours. No cookie is set, nothing loads from an ad network, and even the fonts are served from our own domain. Your own legal review still governs how you describe us - we are a processor, and that list is what we process.

Because the answers were worth something. Those grids doubled as free labelling for the provider's own datasets - visitors were doing unpaid work on the way into a form. Our puzzles produce nothing of the sort. Rotating a disc or dragging a piece into a notch generates no dataset, trains nothing and is worth nothing to us beyond the seconds it takes; there is no second product being built out of your visitors' time.

They get a non-visual challenge as a first-class path, not an audio clip and not a dead end. It is keyboard operable, needs no image and no sound, and relies on no colour cues. A site owner can turn it off per site, but it is on by default.

The edit itself is a few minutes. Our verification endpoint answers in both the reCAPTCHA and the hCaptcha response shapes, so the code already running on your backend keeps working - you change the script tag and the sitekey, and nothing else. After that it is your normal review and deploy. Server SDKs are available for Go, Node, PHP and Python.

10,000 verifications a month are free, which covers most contact, signup and comment forms outright. Beyond that the account needs quota or credits; if both run out we stop issuing challenges and the widget shows a quiet unavailable state rather than breaking your page.

No - and not because we filter that traffic out afterwards, but because the meter never counted it. A verification is charged only when your own backend successfully verifies a token, and each token can be redeemed exactly once. Asking for challenges costs you nothing. Failing them costs nothing. Even solving one costs nothing until your server accepts it. So spending a single unit of your quota means an attacker had to pass a real challenge - a puzzle plus its proof-of-work on the visual path, or a fixed 22 bits of work on the non-visual one - and then get your backend to check the token, by which point it is a request you would have wanted verified anyway. The challenge endpoint is also rate limited to 10 requests a second per address, and once you have listed your domains, a request from any other origin is refused before a challenge is issued.

No. There is no rule file, no signature list and no score threshold to maintain. Difficulty is chosen per request from the risk score, so the protection tracks the traffic instead of a setting you chose once.