Why we do not use classic captchas anymore
Distorted letters and image grids annoy humans, exclude some, and are solved by bots for pennies. What we use instead.
The short answer
The distorted letters, the “select all squares with a bus”, the sliding puzzle: we do not put any of them on client forms anymore, and we remove them when we inherit them. They fail on three counts at once. Bots solve them cheaply, through human solving farms and, increasingly, through vision models. Humans abandon forms because of them, which costs leads. And they are a documented accessibility barrier for people with visual, motor and cognitive impairments. The replacement is a set of layers that is mostly invisible to humans and catches more automated abuse than the puzzle ever did.
Why the puzzle fails
| Problem | What actually happens |
|---|---|
| Bots solve it | Solving services charge fractions of a cent per puzzle; vision models solve most image grids directly |
| Humans give up | Every extra step on a form loses a share of visitors; a frustrating one loses more, especially on phones |
| Accessibility | Visual puzzles exclude blind and low-vision users; audio alternatives are often worse; timed puzzles exclude people who need longer |
| Privacy | Classic services relied on tracking and browsing history to score visitors |
| False confidence | Spam that arrives anyway is blamed on “sophisticated bots” rather than on the weak design |
What we use instead
- Honeypot fields that catch bots filling everything.
- Server-side validation of every field in the function that receives the form, since bots skip the browser entirely.
- Rate limits per source and per form, so one script cannot submit hundreds of times.
- A filtering layer in front that drops known bad sources and bot patterns before they reach the form at all.
- An invisible challenge that scores the request on signals and shows an interactive step only when something looks wrong. Most humans never see it.
- Time and behaviour checks: a form submitted in under a second was not filled in by a person.
- Filtering after receipt: obvious spam patterns are quarantined rather than delivered to the inbox or CRM.
What the numbers show
On forms we have moved from a classic puzzle to the layered approach, two things happen together: spam reaching the inbox drops, and completed submissions from real visitors rise. That combination is only surprising if you believed the puzzle was working. It was mostly working against your customers.
What this means for you
If your forms still show a puzzle, you are losing some visitors to it and stopping fewer bots than you think. Replace it with layers: honeypot, server-side validation, rate limits, a filtering layer in front, an invisible challenge that escalates only when needed. The form gets easier for people and harder for scripts at the same time, which is the right direction for both.
Frequently asked questions
Do we not need some kind of captcha?
You need a way to tell automated abuse from real visitors. A modern invisible challenge does that using signals rather than puzzles, and shows an interactive step only when something looks wrong. Combined with honeypots, rate limits and server-side validation, it catches more than a puzzle and is invisible to nearly every human.
Are the invisible challenges privacy-friendly?
The one we use is designed to avoid tracking and works without cookies for most visitors. Check the provider's documentation and your own privacy notice; it should be listed as a processor like any other service. It is a far lighter footprint than the classic alternatives, which relied heavily on tracking.
We still get some spam through. Is that normal?
A small trickle is normal; some is submitted by humans paid to do it, which no technical measure stops entirely. What matters is that it is small, that it never reaches your CRM unfiltered, and that real visitors are never blocked. If the trickle grows, the layers are tuned, not replaced by a puzzle.
Sources
- Cloudflare developer documentation: Turnstile (accessed 2026-09-11)
- W3C: Inaccessibility of CAPTCHA (accessed 2026-09-11)