What is CAPTCHA, and what does it actually stop?

The accessibility problems are documented by the W3C in Inaccessibility of CAPTCHA.

A Turing test asks whether a machine can pass for a person. A CAPTCHA turns that around: it is run by a machine, it is public, and its aim is to catch the machines. The test is generated automatically, so every visitor can get a fresh one.

The idea rests on a gap between what people do easily and what programs did badly at the time the test was designed: reading distorted text, recognising objects in photos, or moving a pointer the way a hand does.

1. The site decides when to ask. Always on a form, or only when something about the visitor looks automated.
2. A challenge is generated. Distorted text, a set of images to select, an audio clip, a puzzle, or an invisible check that scores behaviour in the background.
3. The answer is checked on the server. A correct answer, or a good enough score, lets the request through; a wrong one asks again or refuses.
4. The result is tied to the request. So that a solved challenge cannot be reused for thousands of later submissions.

Invisible variants ask nothing unless the score is low; all the types side by side are on types of CAPTCHA. They save time for most visitors and move the decision into signals the visitor cannot see or contest. When a check keeps failing for a real person, “Are you a robot?” lists what to try.

A CAPTCHA works only while solving it costs more than the attack is worth. That gap has narrowed. Software now reads distorted text and recognises images well, and paid services employ people to solve challenges cheaply.

So a CAPTCHA filters out the cheapest automation and slows the rest. It does not prove that the visitor is a person, and treating a solved challenge as proof leaves the next layer undefended.

Newer systems often show nothing at all. They watch how the page is used, score the visitor, and show a challenge only when the score is low. Most people never see a puzzle, which removes most of the cost for them.

The trade moves elsewhere. The decision now rests on signals the visitor cannot see or dispute, and a person who is scored wrongly has no way to understand why a form keeps failing. Privacy matters too: scoring behaviour means collecting it, and where that data goes depends on who runs the check.

The W3C note on CAPTCHA inaccessibility lists who is shut out: blind visitors using screen readers, people with low vision or dyslexia, deaf-blind people for whom the audio version does not help, people with cognitive disabilities who cannot solve puzzles under time pressure, and anyone who does not read the language the test assumes.

Everyone else pays in time and patience. Each challenge on a sign-up or a checkout is a point where some real visitors give up, and the site rarely learns how many.

Use it where a single action is cheap for an attacker and expensive for you, and only after other signals say the request is suspect. NIST's guidance on sign-in throttling, SP 800-63B section 5.2.2, lists a CAPTCHA as one of several ways to slow repeated attempts without locking real users out, alongside growing delays and risk-based checks.

Always offer an accessible alternative path, and measure how many people abandon the form; checks that ask people nothing are on CAPTCHA alternatives. For protecting sign-in specifically, see brute force attacks and credential stuffing.