The claim on the tin
A captcha is described as telling humans and computers apart. That was roughly true when the test was reading distorted text, and it has not been true for years. Automated recognition surpassed human accuracy on distorted characters some time ago, and the remaining gap was closed commercially — solving services employ people to answer challenges at a price measured in fractions of a cent.
That price is the important number, and it reframes the whole control. A captcha does not establish humanity. It imposes a cost, and it works when that cost exceeds what the attempt is worth. Every design decision follows from this, and most deployment mistakes come from believing the original claim rather than the economic one.
What the test actually measures
Modern implementations spend less effort on the puzzle than on everything around it. The signals that carry weight are:
- Address reputation. Where the request comes from, what else that address has done recently, whether it belongs to a datacentre, a residential proxy pool, or an ordinary consumer connection.
- Client consistency. Whether the browser's claims about itself agree with each other. A user agent claiming one browser while the TLS handshake, header ordering and capability set indicate something else is inconsistent in a way genuine clients rarely are.
- Interaction texture. Whether the pointer, keyboard and scroll behaviour resemble a person operating a device. Not whether it is perfect — human input is noisy — but whether the noise has the right character.
- Request context. Whether this visitor arrived through a plausible sequence of pages, or appeared directly at the endpoint that matters.
The visible challenge is often the smallest part of the decision, and increasingly appears only when the other signals are inconclusive. When a user ticks a box and passes instantly, the box was not the test.
Why bots still get through
Given all that, failures are usually explained by one of four things.
The economics favoured the attacker. If an account is worth more than the cost of solving, solving is a rational purchase. Against high-value targets, a captcha is a toll rather than a wall. This is not a defect in the implementation; it is the control operating exactly as designed against an adversary who can afford it.
The bot was more human than expected. Automation driving a real browser on a residential connection produces genuine TLS characteristics, real rendering behaviour and plausible input. Many signals a captcha depends on simply are not distinguishing in that case.
The captcha was in the wrong place. Protecting a login form accomplishes nothing if an API endpoint reaches the same authentication logic without one. Attackers enumerate; they use whichever entry asks for least. A great many "the captcha didn't work" reports are really "the captcha wasn't there".
The token was never checked. A widget that renders and produces a token accomplishes nothing unless the server verifies that token before acting. This failure is more common than it should be and is invisible in testing, because the form works perfectly for everyone including the attacker.
The cost nobody accounts for
Captchas are not free to legitimate users, and the cost falls unevenly.
Visual challenges exclude users with visual impairments, and audio alternatives are often worse. Users on shared or mobile networks inherit the reputation of everyone else on that address. Privacy-conscious users running tracker blocking or a VPN look precisely like the traffic being filtered. Users on older devices or slower connections fail interaction heuristics tuned on modern hardware.
Every one of those groups is more likely to be challenged, more likely to fail, and more likely to abandon. That abandonment does not appear in security metrics — it appears in conversion, in a different team's dashboard, attributed to something else. Tuning aggressiveness without measuring completion rate across client types optimises one number by silently damaging another.
Where the control belongs
A captcha is one signal in a decision, not the decision.
It belongs at the point where an action becomes expensive or irreversible: account creation, password reset, checkout, message submission. It does not belong on every page, and it does not belong where a rate limit would do the same job with no user cost at all.
It should be one input to a risk score rather than a binary gate. Most visitors should never see a challenge; the challenge should escalate as other signals get worse. A system that shows the same puzzle to everyone is both the most annoying and the least informative configuration available.
It must be verified server-side, on every path that can perform the action, with a token that cannot be replayed. If that verification is missing or scoped to one route among several, everything upstream is decoration.
And it must be measured on both sides. Track what it blocks and what it costs — challenge rate, completion rate, and abandonment segmented by client and network type. A captcha that blocks a great deal of automation while quietly costing a percentage of real sign-ups is not obviously a good trade, and you cannot tell whether it is one without the second number.
The honest position
A captcha is a cost-imposition device with a real but bounded effect. It reliably stops opportunistic, low-value automation, which is the overwhelming majority of hostile traffic on most sites. It does not stop a motivated attacker with a budget, and it was never able to.
Deployed as one signal among several, at the points that matter, verified properly and measured on both sides, it is a good control. Deployed as a wall, on the assumption it proves humanity, it produces the worst outcome available: determined attackers pass, ordinary users are inconvenienced, and the metric that would reveal the trade is never collected.