Is CAPTCHA still effective, and what should you use instead?

Is CAPTCHA still effective?

CAPTCHA is no longer an effective primary control against modern, economically motivated abuse. It still stops unsophisticated scripts. It does not stop solver farms, vision models, or token replay, and it taxes every legitimate user who hits the widget. Use it as a rare step-up on a high-risk action. Build the real defense from adaptive rate limiting, identity-aware quotas, and behavioral bot detection in the request path.

CAPTCHA was designed for a web where bots were simple scripts from a small set of addresses. That world is gone. Attackers use residential proxies, human solver APIs, and AI-assisted tooling. Legitimate users expect a fast, invisible experience on mobile and in privacy-hardened browsers. The gap between those two facts is why a puzzle on every signup looks like security and behaves like friction.

If you are protecting login, signup, checkout, or an AI inference route, ask whether a challenge solves the actual problem. Most of the time it does not. For more information about the detection stack that should sit underneath any challenge, see bot detection techniques.

How does CAPTCHA work?

CAPTCHA is a challenge-response test. The system presents a task that is supposed to be easy for a human and hard for software. A correct solution produces a verification token. The server treats that token as evidence that a person is present.

Implementations include distorted text, image grids, checkboxes, and invisible scores that watch mouse movement or device signals. Underneath, most vendors combine client-side telemetry, a centralized risk model, and a short-lived token you verify over HTTP.

The founding assumption is that automation cannot solve the challenge at scale, so requiring a solution raises the cost of abuse. That assumption held when computer vision was weak and solver labor was expensive. It does not hold when a solve costs a fraction of a cent and a stolen account is worth tens of dollars.

How do bots bypass CAPTCHA?

Teams look for clever exploits. In production, bypass is usually economic.

Human solver farms. A script hits your challenge, posts it to a solver API, and continues with the token. From your app the flow looks like a person. Solver services advertise image CAPTCHAs at roughly $1 to $5 per thousand, so 100,000 checkout attempts cost on the order of $100 to $500 in solves. Check current rates yourself rather than trusting a figure in an article; they move. The arithmetic is the point, and it does not depend on the exact rate: as long as one fraudulent order is worth more than a thousand solves, the puzzle is a line item rather than a deterrent.

AI solvers. Image and text challenges are standard vision benchmarks. Attackers fine-tune models on common variants. They do not need perfection. Partial success at high throughput is enough when the attack is profitable.

Session replay and token harvesting. Advanced operators skip the puzzle. They reuse a valid token, extract one from a compromised client, or proxy through a real browser so they inherit trusted signals. If your backend accepts the token without checking velocity, identity consistency, or the rest of the request, the challenge is a thin gate.

CAPTCHA is not "broken" in the cryptographic sense. It is outsourced and underpriced.

What is the conversion cost of CAPTCHA?

Even a moderately effective puzzle has product costs. Image challenges are painful on small screens. Accessibility suffers for users with visual or motor impairments. Privacy browsers and extensions block third-party scripts, which produces failures that look like user error. Vendor scripts add latency and a dependency you do not control.

Conversion loss from a universal challenge is widely reported, but the public numbers come from vendor studies and one-off A/B tests with different traffic mixes, challenge types, and definitions of abandonment, so no single figure travels. Do not budget against a number you read in an article, including this one. Measure it: run the challenge on half your traffic for a week and compare completion on the flow you care about. The mechanism is what is stable, not the magnitude. You moved the cost of abuse onto every legitimate user, so the loss scales with how many of them are legitimate.

From a product view, that is a tax on growth. From an engineering view, it often means the system has no deeper control at the API. You asked the browser to prove humanity because the handler cannot constrain the operation.

CAPTCHA alternatives compared

The replacement is not "no challenge." It is context-aware enforcement: evaluate traffic continuously, constrain abuse at the protocol and identity layers, and apply friction only when risk is high. The following table compares CAPTCHA with the three controls that should sit in front of it.

Layer the last three. Keep CAPTCHA as a fallback when you have a human in a browser and the other signals are inconclusive.

How does adaptive rate limiting replace a puzzle?

Fixed per-IP windows fail against proxy pools. Adaptive, identity-aware limits succeed because they constrain the scarce operation, not "HTTP from this address."

Effective replacements include:

• Per-account ceilings on login, so stuffing from thousands of IPs still shares one budget.
• Per-API-key or per-user quotas on JSON and inference routes.
• Sliding windows, which remove the 2× boundary burst of a naive fixed window.
• Token buckets, which allow a legitimate burst and still cap sustained abuse.
• Progressive backoff: log, then tighten, then delay, then challenge, then deny.
• Different thresholds per route. Signup is not search. Inference is not a health check.

Unlike a widget, a limit protects the API directly. Bots target /login, /checkout, and /v1/complete. They do not have to render your page. For more information about algorithm trade-offs, see the rate limiting guide.

How do you protect AI APIs without CAPTCHA?

A browser challenge cannot defend an endpoint that never renders HTML. Attackers call inference routes with a key, a stolen cookie, or an open handler. Each request burns GPU time, so the failure mode is a bill, not a full inbox.

Protect those routes with authentication, per-identity token or request budgets, and anomaly detection on usage shape (sudden fan-out, repeated worst-case prompts, one key hitting every model). Apply bot detection on the HTTP request. Do not ask the model to "detect bots." For more information about valid operations used for a harmful outcome, see what is API abuse.

What should you use instead of CAPTCHA?

Design for automation as the default. Enforce identity-aware limits. Detect bots from request context. Challenge only when a human is present and risk is high.

A practical Next.js handler composes Shield, bot detection, and a fixed window. Pin @arcjet/next to v1. Pass allow or deny to detectBot, never a block list. On a write route, allow: [] is the right default: nothing automated has a reason to submit your form. Keep CATEGORY:SEARCH_ENGINE for the public GET pages you want indexed.

1
import arcjet, { detectBot, shield, fixedWindow } from "@arcjet/next";
2

3
const aj = arcjet({
4
  key: process.env.ARCJET_KEY!,
5
  rules: [
6
    shield({ mode: "LIVE" }),
7
    detectBot({
8
      mode: "LIVE",
9
      // Nothing automated should be posting this form.
10
      allow: [],
11
    }),
12
    fixedWindow({ mode: "LIVE", window: "1h", max: 100 }),
13
  ],
14
});
15

16
export async function POST(req: Request) {
17
  const decision = await aj.protect(req);
18
  if (decision.isDenied()) {
19
    if (decision.reason.isBot()) {
20
      return new Response("Forbidden", { status: 403 });
21
    }
22
    if (decision.reason.isRateLimit()) {
23
      return new Response("Too Many Requests", { status: 429 });
24
    }
25
    return new Response("Forbidden", { status: 403 });
26
  }
27
  return new Response("OK");
28
}

On signup, prefer a bundled rule that also verifies email. On login, key a tighter window on the account. On inference, key a token bucket on the API key and the model. Start in DRY_RUN, compare conversion and abuse outcomes, then promote.

CAPTCHA can remain in the drawer for a suspicious password reset from a new device. It should not be the product you ship on every form.