Invisible CAPTCHA
What is Invisible CAPTCHA?
An invisible CAPTCHA reaches a verdict about whether a person is present without asking them to do anything. There is no puzzle and no checkbox. The script observes how the browser behaves, collects signals, and returns a token the server verifies.
It is the same challenge-response protocol as a visible CAPTCHA — challenge, response, server-side verification — with the response assembled by the browser rather than typed by a person.
What it reads
An invisible check has to decide on evidence that is available without interaction. In practice that is four families of signal:
| Signal | What it shows |
|---|---|
| Interaction | Pointer paths, scroll rhythm, typing cadence, the pauses between actions |
| Browser environment | Which APIs exist and how they behave, canvas and WebGL output, font metrics |
| Network and timing | TLS characteristics, request ordering, round-trip timings against plausible distance |
| Proof of work | A computation the client must complete, charging CPU time per attempt |
No single one of these decides anything. A headless browser can be made to report a plausible environment; a script can be given curved mouse paths. The verdict comes from whether the whole set is internally consistent, which is considerably harder to fake than any individual value.
Invisible describes the experience, not the strength
"Invisible" describes the user experience, not the strength. An invisible CAPTCHA that only inspects the user-agent string is weaker than a visible puzzle, and such implementations exist — the whole check being a short script that reads a header an attacker fully controls.
The question to ask a vendor is not whether the check is invisible but what it does when the signals are ambiguous. There are only three possible answers, and it is worth knowing which you are buying: allow the request, block it, or escalate to a visible challenge. A product that always allows under uncertainty is providing a user experience rather than protection.
The accessibility case
The strongest argument for invisible checks is not convenience, it is that visible ones exclude people. Image grids are difficult or impossible for users with visual impairments; audio alternatives are unreliable and tedious; timed puzzles penalise people with motor or cognitive differences. A check that asks nothing cannot fail any of those users.
That advantage disappears the moment the product escalates to a puzzle, which is why the escalation path matters as much as the invisible path — anything that falls back to a traffic-light grid under load has simply deferred the problem.
How Procaptcha implements it
Procaptcha runs the invisible check by default, combining the signal families above with proof of work where it is configured, and verifies the resulting token server-side. Sessions that cannot be decided on behavioural evidence can be escalated, and the data handling is deliberately narrow: no third-party tracking cookies and no requirement to process in the United States, which is the usual reason a privacy review rejects a CAPTCHA.