There's a pattern you can watch happen on any reasonably popular site once a quarter. A team ships a new sign-up flow. They add reCAPTCHA. The bots keep coming. They upgrade to reCAPTCHA v3 invisible. The bots keep coming. They switch to hCaptcha for privacy reasons. The bots keep coming. They try Cloudflare Turnstile. The bots keep coming. Somewhere around month four, somebody writes a Slack message that reads "what if we just made it harder for real users?"
This is not a story about a particular CAPTCHA being broken. It's a story about a category that has lost its asymmetric advantage. The defining property of an effective CAPTCHA — that it costs more for an attacker to solve than for a legitimate user — has been priced into oblivion. Solvers cost a fraction of a cent. Vision models do the rest for free. Real users churn.
What a CAPTCHA Was Supposed to Do
A CAPTCHA, in the 2003 sense Luis von Ahn coined, is a "Completely Automated Public Turing test to tell Computers and Humans Apart." The asymmetry depends on three properties:
- The challenge is hard for current machine learning.
- The challenge is easy for typical humans.
- The cost to generate the challenge is much lower than the cost to solve it.
All three were approximately true for distorted-text CAPTCHAs in 2003. None are true for any visual CAPTCHA in 2026.
The death of (1) is what people mean when they say CAPTCHAs are broken. The death of (2) is what people mean when they say CAPTCHAs are user-hostile. The death of (3) is the boring one that actually matters, because it's the one that breaks the economics for defenders.
The Solver Economy
Here's the part that doesn't get talked about enough. CAPTCHAs are not defeated primarily by AI. They are defeated by markets that price AI at scale.
2Captcha, CapSolver, AntiCaptcha and a long tail of grey-market resellers operate as commodity APIs. You send a challenge image or sitekey, you get back a token, you pay per solve. Pricing as of mid-2026, in round numbers:
| Challenge type | Price per 1,000 solves | Median solve time |
|---|---|---|
| reCAPTCHA v2 (image grids) | $1.50 – $3.00 | 8 – 15 s |
| reCAPTCHA v3 (invisible) | $1.50 – $2.50 | 1 – 3 s |
| hCaptcha | $1.00 – $2.50 | 8 – 12 s |
| Cloudflare Turnstile | $1.50 – $3.00 | 4 – 10 s |
| Arkose Labs FunCaptcha | $3.00 – $7.00 | 15 – 30 s |
| Audio CAPTCHA | $2.00 – $4.00 | 15 – 25 s |
Translate that into attacker math. A credential stuffing operator running 100,000 attempts a day at a 0.3% hit rate, valuing a validated account at $20, makes $6,000/day in revenue against $300 in solver cost.
CAPTCHA is a 5% line item in their cost of goods sold. It is not a deterrent. It is a tax an attacker pays without complaint while extracting value from your system.
The Autopsy, By Variant
reCAPTCHA v2 image grids. Solved end-to-end by GPT-4-class vision models in 2023, and by smaller, cheaper fine-tuned models since. Solve rate against modern grids is consistently above 90% — higher than the average human solve rate against the same puzzles. The audio accessibility fallback is solved by Whisper with similar reliability.
reCAPTCHA v3 invisible scoring. Three concrete problems. The score is gameable — operators run checkers in real Chrome with warm Google session cookies on seasoned residential profiles, scoring 0.7–0.9. The score routinely flags legitimate users on Linux, Firefox, hardened browsers, or VPNs, often below 0.3. And every page shipping v3 is also shipping a Google tracking beacon to every visitor, which is a live regulatory issue under GDPR and US state privacy laws.
hCaptcha. Functionally similar to v2 with a privacy-first marketing posture. Solved by the same providers at similar prices with similar success rates.
Cloudflare Turnstile. The most interesting of the modern lot, because it skips the puzzle and scores on browser environment signals. When it works, it works invisibly. When it fails, it fails opaquely. Two failure modes we see in the wild: it passes Browser-as-a-Service traffic (Browserbase, Hyperbrowser) with high frequency, because those platforms serve real Chromium on real residential IPs; and it blocks a long tail of legitimate users on hardened privacy browsers (Brave strict shields, LibreWolf, Tor) at rates that produce real conversion impact. Right shape for the future, closed implementation tied to one edge.
Arkose FunCaptcha. Long the holdout because of the 3D-rotation requirement. By 2025, depth-aware vision models trained on synthetic 3D renders started solving these reliably.
The Shape of the Replacement
Six independently useful components. Most production stacks combine three or four. None are silver bullets — the point is that combining cheap signals raises attacker cost faster than any single signal does.
1. Behavioral biometrics
Real humans interact with a page in characteristically messy ways. Continuous mouse trajectories with micro-tremors at 3–25 Hz from physiological hand movement. Hover, overshoot, correct. Inter-keystroke intervals that follow a log-normal distribution with dwell-time variance, rollover on common letter pairs, and real Shannon entropy.
Automated browsers can replay recorded human traces — that's the obvious counter. The current state of play is that replayed traces look right at first order (mouse moves, things get clicked) but break under second-order analysis: the trace doesn't match the page layout the model is currently looking at, keystroke entropy is uniform across the corpus, the timing distribution has a different tail.
Signals worth capturing, in rough order of cheapness:
- Mouse trajectory entropy and curvature
- Inter-event timing distributions (keystroke, mouse move, scroll)
- Field-fill order and time-on-form
- Pointer move events between page load and first click
- Touch vs mouse vs synthetic event detection (
event.isTrusted) - Scroll velocity profiles
- Focus and blur event sequences
2. Proof-of-work
The oldest idea in the deck, and one of the most underused. Adam Back's 1997 Hashcash proposal is the original spec: before accepting a request, require the client to find a partial SHA-256 collision against a server-issued nonce. Tunable difficulty, no interactivity, invisible to the user.
The asymmetry is straightforward. A 200 ms PoW solve on a real phone is below the threshold of perception. The same 200 ms across 10,000 parallel sessions is 33 minutes of single-threaded compute, or a real cloud bill in parallel. Worth nothing against someone targeting one account. Crippling for mass-volume operators.
async function solve(nonce, difficultyBits) {
const target = (1n << (256n - BigInt(difficultyBits)))
for (let counter = 0; ; counter++) {
const buf = new TextEncoder().encode(nonce + counter)
const digest = await crypto.subtle.digest('SHA-256', buf)
const hashInt = BigInt('0x' + [...new Uint8Array(digest)]
.map(b => b.toString(16).padStart(2, '0')).join(''))
if (hashInt < target) return counter
}
}
Difficulty calibration is the only interesting tuning question. Too low and it doesn't bite; too high and slow phones see a noticeable delay. We land around 20 to 22 bits, roughly 100–400 ms on a five-year-old Android and well under a second on anything modern.
3. Privacy Pass and Private Access Tokens
The most promising long-term direction. A trusted attester (Apple, Google, your own service) verifies the client is a real device, then issues a blind cryptographic token the client redeems at your service. You learn the request came from an attested human-controlled device. You learn nothing else. The attester learns nothing about which sites the user visits.
The catch in 2026 is coverage: well-supported on Apple platforms, partially on Cloudflare's network, effectively unsupported elsewhere. PAT is part of the stack, not the whole stack.
4. TLS and HTTP/2 fingerprinting
The layer below the browser. Every HTTP client has a TLS ClientHello with a specific cipher suite ordering, extension list, and supported groups; every HTTP/2 client has a settings frame with specific values and pseudo-header order. These vary by client library and stack version, and are very hard to spoof from a script without driving an actual browser.
A POST that arrives with User-Agent: Mozilla/5.0 ... Chrome/124 and a JA4 fingerprint that says "Go HTTP client" is automated. Full stop. No human Chrome ever produced that combination.
5. Honeypot fields and decoy endpoints
The oldest cheap trick still works for a useful slice of the threat. Two important caveats, though. Classic CSS-hidden honeypots (display: none) are increasingly invisible to vision-based agents that read the rendered page rather than the HTML — the agent never sees the field, so it never fills it. And accessibility tooling sometimes interacts with hidden fields, producing false positives for screen-reader users.
The patterns that hold up in 2026 use DOM-tree placement (a field after the submit button), naming conventions that look real but never appear in your actual schema, or Shadow DOM containment that mainstream automation libraries don't traverse.
6. Server-side risk scoring
The layer that ties everything together. Every signal above produces a feature; score requests across all of them and decide what to allow, what to challenge with a step-up, and what to silently drop.
The thing to avoid is a single hardcoded "bot or not" threshold. The thing to embrace is a graduated response that maps risk score to action.
How They Combine
A realistic 2026 stack on a high-value form:
1. Edge
- TLS / HTTP/2 fingerprint logged
- Datacenter ASN gets harder PoW difficulty
- Known-bad fingerprint clusters hard-blocked
2. Page load
- Behavioral telemetry script attached
- Keystroke, mouse, scroll, focus events captured
- Honeypot fields rendered into the DOM
- PoW challenge issued at low difficulty
3. Submit
- Form + signed telemetry token + PoW result posted
- Honeypot fields verified empty
- Server computes risk score across all signals
4. Decision
- Score below A: accept silently
- Score in band: step up (harder PoW or soft MFA)
- Score above B: drop with response symmetry
(identical status, body shape, timing)
What you do not do, in any layer, is show the user a visual challenge.
An open-source implementation
FCaptcha is our open-source implementation of this stack (currently v1.37). We started it because every team that came to us asking how to replace reCAPTCHA wanted the same three things: an open-source library, a self-hostable server, and a scoring algorithm they could read and audit.
What's in the box: behavioral telemetry across mouse/keystroke/scroll/focus/environment categories; keystroke cadence biometrics (dwell variance, log-normal fit, Shannon entropy, autocorrelation, rollover detection); SHA-256 proof-of-work with server-side timing validation; vision-AI detection (zero-movement click bypass, screenshot-to-API patterns, synthetic event filtering); automation detection for Playwright, Puppeteer, Selenium, Stagehand and BaaS; servers in Go, Python and Node with identical scoring semantics; no cookies, no cross-site tracking, no PII.
1. Run the server.
docker run -d -p 3000:3000 \
-e FCAPTCHA_SECRET=your-secret \
ghcr.io/webdecoy/fcaptcha
That gives you POST /api/* for verification and GET /fcaptcha.js for the widget. Two deployment notes worth knowing up front: the server fails closed without FCAPTCHA_SECRET (the public dev key is in the repo, so anything signed with it can be minted by anyone), and running more than one replica requires REDIS_URL so single-use tokens are single-use across the whole deployment rather than per process.
2. Add the widget. Invisible mode auto-protects forms with no UI:
<script src="https://your-server.com/fcaptcha.js"></script>
<script>
FCaptcha.configure({ serverUrl: 'https://your-server.com' })
FCaptcha.invisible({ siteKey: 'your-site-key', autoScore: true })
</script>
3. Verify on the backend. A plain HTTP POST:
import requests
resp = requests.post(
'https://your-server.com/api/token/verify',
json={'token': token_from_form, 'secret': FCAPTCHA_SECRET},
).json()
# In FCaptcha, a LOW score means the request looks human.
if resp['valid'] and resp['score'] < 0.5:
return accept()
elif resp['valid'] and resp['score'] < 0.8:
return require_step_up()
else:
return reject()
What we don't claim
This does not "solve bot detection." Nothing does. It raises the cost of mass-volume automated abuse to the point where commodity attackers move on and bespoke attackers leave signals you can act on. Targeted attackers with patient capital and real Chromium on real residential bandwidth will still get through. That's true of every defense in this category.
Behavioral telemetry can be replayed. Open datasets of recorded human interactions exist for the explicit purpose of training automation to look human. The signals that hold up are second-order ones — does the trace match the current page, does the keystroke entropy match the current user's history. Harder to replay convincingly. Not impossible.
Proof-of-work is not free for clients. A 200 ms hit is small but not zero. On a four-year-old phone with thermal throttling it can stretch to 800 ms. Tuning difficulty by device class means low-trust devices get more friction, which is its own UX cost.
No CAPTCHA replacement is GDPR-trivial. Behavioral telemetry is biometric data under EU law, and the scoring is opaque enough that "right to explanation" obligations require thought. You will still need a privacy review.
A migration path
If you're on reCAPTCHA today, the path that has worked for most teams:
- Week 1 — Ship behavioral telemetry alongside the existing CAPTCHA. Log scores, don't gate on them. Build a dashboard of score distributions for known-good and known-bad sessions.
- Weeks 2–3 — Calibrate thresholds against the labeled dashboard. Find the band that cleanly separates confirmed humans from confirmed bots, and the gray middle that needs step-up.
- Week 4 — Move the CAPTCHA into step-up-only mode. Default flow is invisible; only the gray band sees a challenge.
- Weeks 5–6 — Replace the CAPTCHA step-up with a higher-difficulty PoW step-up, or soft MFA for accounts that have it.
- Week 7 — Remove the CAPTCHA SDK entirely. Audit the privacy footprint reduction. Tell your conversions team.
Most teams measure a conversion lift on legitimate sign-up traffic at step 3 — the moment the CAPTCHA stops gating clean sessions — and a sharper drop in confirmed bot success by step 5.
Where this goes next
Agent-driven traffic from real Chromiums. The Browser-as-a-Service ecosystem is industrializing exactly the population that defeats most behavioral defenses. Cross-session correlation, JA4-plus-device-fingerprint binding, and challenge interaction physics beyond first-order signals all matter more in this world.
Standardized client attestation. PAT is the early form. WebAuthn-anchored device attestation, TPM-backed remote attestation, and App Attest are converging toward a future where "is this a real device controlled by a real user" is a cryptographic question rather than an inferential one. Uneven and partial today. Worth tracking.
The CAPTCHA is dead. What replaces it is not one thing — it's a stack of cheap, layered signals producing a real-time score, paired with a graduated response that mostly does nothing visible to the user. That's the bar. Everything below it is theater.
Either way: please stop making people click on traffic lights.
What are you running on your sign-up flow right now? Curious how many teams have actually managed to rip reCAPTCHA out versus just layering on top of it.
Originally published at webdecoy.com.
Related reading:
Top comments (0)