How a CAPTCHA works
CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart. Researchers at Carnegie Mellon University coined the name in 2003, and the idea has not changed since: ask something that is easy for a person and hard for a program, and accept the request only if the answer is right.
Every CAPTCHA, from a wobbly word to an invisible check, runs in three steps. The widget runs in the visitor's browser and produces a token, proof that a challenge was passed. The browser sends that token along with the form. Your server then asks the CAPTCHA provider whether the token is genuine, before it creates the account or sends the message.
The third step is the one that gets skipped, and without it the widget is decoration: a bot simply posts the form without a token, or with an old one. Tokens are short-lived and single-use for exactly this reason, so the check has to happen on the server, on every submission.
Server-side verification: the step that makes the widget mean something
curl -s https://www.google.com/recaptcha/api/siteverify \
-d secret="$RECAPTCHA_SECRET" \
-d response="$TOKEN_FROM_THE_FORM"
# {"success": true, "hostname": "example.com", ...}
# hCaptcha and Turnstile work the same way, each with its own siteverify URL.The types: from wavy letters to no puzzle at all
Text CAPTCHAs show distorted letters and numbers. They were the first generation and are now the weakest: character recognition software reads them better than many people do.
Image CAPTCHAs ask you to select every square with a traffic light or a bicycle. Audio CAPTCHAs read out digits over background noise and exist mainly as the accessible alternative to the first two.
reCAPTCHA v2, Google's checkbox, changed the model in 2014. The "I'm not a robot" tick is mostly a moment for the script to look at the browser and how it behaved; only a visitor it is unsure about gets the image grid. Its invisible variant drops the checkbox and shows the grid only when needed.
reCAPTCHA v3 (2018) shows nothing at all. It returns a score between 0.0 and 1.0 for each action, and your server decides what a low score means: refuse, ask for a second factor, or send the submission to moderation.
hCaptcha follows the v2 model, with background checks and a picture task when in doubt, and positions itself on privacy; its enterprise tier adds risk scores.
Cloudflare Turnstile (2022) replaces the puzzle with a rotating set of non-interactive checks that run in the browser, and it is free to use on any site, not only on sites behind Cloudflare. Its widget has three modes: managed (a checkbox only when the checks are unsure), non-interactive and invisible.
The direction is plain from the list: each generation asks the visitor less and the browser more.
What a CAPTCHA costs you
Time, and the conversions behind it. A large Stanford study in 2010 measured about 10 seconds for people to solve an image CAPTCHA and close to 30 seconds for an audio one, and the audio answers were often wrong. Each of those seconds sits between a visitor and the thing they came to do: sign up, pay, ask you a question.
Accessibility. A visual puzzle shuts out blind and low-vision visitors, and the audio fallback is hard for everyone and useless to someone who can neither see nor hear well. The W3C has published a note devoted entirely to the inaccessibility of CAPTCHA, and WCAG requires that a CAPTCHA come with an alternative for a different sense.
Privacy and page weight. The widget is a script from the provider, loaded on your page, that sees the visitor's browser; that belongs in your privacy notice. It is also a sizeable piece of third-party JavaScript, so load it only on the page that has the form, never site-wide.
Getting people wrong. Risk-based systems learn what typical traffic looks like, and people on VPNs, privacy-focused browsers or a busy office connection look less typical. They get more puzzles, or a lower score, for doing nothing wrong.
Why puzzles stopped being enough
A CAPTCHA works only while solving it is cheaper for a person than for a machine. That stopped being true some time ago.
Machines got better. Text CAPTCHAs fell to character recognition first, image grids to modern image models later. A 2023 study presented at USENIX Security found bots solving several widely used CAPTCHA types faster than people, and distorted text more accurately.
People got cheaper. Where software fails, CAPTCHA-solving services route the puzzle to human workers and return the answer through an API, for a few dollars per thousand solves. To a spammer that is a rounding error; to your real visitors the puzzle is the same ten-second annoyance it always was.
So today a CAPTCHA mostly filters out cheap automation: scripts that never bothered to look like a browser. That is still worth doing at the door of a form. It is not a defence for the rest of the site, and the value of the modern systems lies in the signals they collect, not in the puzzle they occasionally show.
The invisible alternatives
These are the checks that replace the puzzle. None of them asks the visitor anything, and they are strongest together.
JavaScript challenge. The server answers a suspicious first request with a small page that runs a script in the browser. A real browser finishes it in about a second and receives a signed cookie; a script that only downloads HTML never gets past it. The visitor sees a brief "checking your connection" page, or nothing at all.
Proof of work. A variant in which the browser solves a small computational puzzle. People do not notice it, but it makes every request cost a bot CPU time, which adds up at scale.
Rate limiting. Counts requests per client over time. A person reads a page and clicks a few links a minute; a scraper makes hundreds. Counting catches behaviour that no single request reveals.
Bot scores and risk signals. Where a request comes from (a home connection or a data-centre network), whether its headers fit the browser it claims to be, how it behaves across requests. Some systems fold these into one score; others act on named signals. Either way, the decision is made before the page is served.
Honeypot fields. A form field hidden from people with CSS. Humans leave it empty; naive bots fill in every field and give themselves away. Free, invisible, and effective against cheap spam.
Verified crawlers. Search engines must get through all of the above untouched. They are recognised by the network they come from, not by their user-agent string, which anyone can type.
Where a CAPTCHA still belongs
On a form where a single successful submission is worth something to an attacker: account sign-up, password reset, contact and comment forms, gift-card and coupon fields. There, one extra step for a person is a fair price, and a server-verified token is exactly the right control.
That is how we use it ourselves. The cdn.com.tr sign-up and contact forms carry a checkbox CAPTCHA, and on the pricing page the CAPTCHA script loads only when the enterprise contact form is opened, so nobody browsing prices downloads it.
Where it does not belong: ordinary page views, product listings, articles, APIs and mobile apps. A puzzle in front of browsing taxes every visitor to stop traffic that an invisible check at the edge stops better.
How CDN.com.tr protects a site without a puzzle
Bot protection on cdn.com.tr is a JavaScript challenge that runs on the edge, in front of your origin. In the panel it is the Bot Protection (JS Challenge) card under Protection → Security, with three modes: off, risky visitors (recommended) and everyone. A mode change reaches the edge by itself; there is nothing to deploy.
In risky-visitors mode, only requests that carry a risk signal are challenged: traffic from data-centre and cloud networks, where real readers rarely browse from; a client that claims to be a search engine but arrives from a network that engine does not use; a missing or near-empty user agent; and a burst of page views from a single address. A reader on a home or mobile connection sees nothing.
Only page navigations are challenged. Images, stylesheets, scripts, API calls and form posts pass untouched, so your cache hit ratio and your applications are unaffected. Verified search engine crawlers (Google, Bing, Yandex, Apple and DuckDuckGo) always pass, checked against the network they really come from rather than the name they send, so the challenge never costs you indexing.
A challenged visitor sees a short "Checking your connection" page for about a second, in their own language (seven are built in, English for the rest), and then the page they asked for. The check page goes out as a 503 with noindex, so it can never end up in search results. A visitor who passes is not asked again for 30 minutes, and the clearance cookie is bound to their address and browser, so it cannot be copied to another machine.
Everyone mode puts the first page view of every new visitor through the check. It is a lever for the middle of an attack, not a setting for ordinary days, and the panel asks for confirmation before switching it on.
What it stopped, and what stands behind it
That is the ceiling of any JavaScript challenge: a bot that drives a real browser can run the script. It is why the challenge is one layer of several on the same edge. A rate limit, set account-wide or per delivery rule and counted per client address, answers anything over its budget with a 429, which is what makes a fleet of headless browsers expensive. The WAF inspects what requests carry, and country and ASN rules shut out a network you never want to hear from with a 403.
The challenge card keeps its own statistics: challenges served, challenges passed, verified crawlers let through, why visitors were challenged and which networks were challenged most, for the last hour, day, week or month. A pass rate near zero is the result you want. It means what was stopped was not people.
Choosing the right tool
Pages scraped or flooded by clients that look like browsers: bot protection in risky-visitors mode.
An attack in progress: everyone mode for its duration, then back to risky visitors.
Password guessing on a login page: a strict rate limit on that path, and a CAPTCHA on the form.
Spam sign-ups and contact messages: a CAPTCHA or Turnstile on the form, verified on the server, plus a honeypot field.
Traffic from a network you never serve: an ASN or country rule.
Malicious payloads such as SQL injection: the WAF. A challenge checks who is asking, not what they send. For volumetric floods, see DDoS protection.
Frequently asked questions
What does CAPTCHA stand for?
Completely Automated Public Turing test to tell Computers and Humans Apart. The term was coined in 2003 at Carnegie Mellon University. The "Turing test" part refers to Alan Turing's test of whether a machine can pass as human, turned around: here a machine is the judge.
Is reCAPTCHA v3 still a CAPTCHA if it shows nothing?
It is the same service with a different contract. v3 never shows a puzzle; it returns a score from 0.0 (likely a bot) to 1.0 (likely a person) for each action, and your server decides what to do with it. That makes it a bot score rather than a test, and the important work, choosing thresholds and what happens below them, is yours.
Can bots solve CAPTCHAs?
Yes. Image models solve text and image puzzles, and solver services pass the rest to paid human workers for a few dollars per thousand. A CAPTCHA still filters out cheap automation, which is most spam, but it should not be your only defence.
Is Cloudflare Turnstile only for sites on Cloudflare?
No. Turnstile is a widget plus a server-side verification call, and it works on any site, including sites served through another CDN. Like every CAPTCHA, it protects only if your server verifies the token on each submission.
Do CAPTCHAs or bot challenges hurt SEO?
A CAPTCHA on a form does not, because crawlers do not submit forms. A challenge in front of pages would, if it stopped crawlers. That is why the cdn.com.tr challenge lets verified Google, Bing, Yandex, Apple and DuckDuckGo crawlers through and sends its check page as a 503 with noindex, so it is never indexed.
If I turn on bot protection, do I still need a CAPTCHA?
On forms attackers want to submit, yes. The challenge decides who may load your pages; it does not look at form posts. Sign-up, login and contact forms keep their CAPTCHA, and a rate limit on those paths caps how fast anyone can try.
What does a challenged visitor see?
A short "Checking your connection" page in their language for about a second, after which the page they asked for loads by itself. JavaScript must be enabled in their browser. Once they pass, they are not asked again for 30 minutes.