A challenge is issued
The small loader asks for a signed, short-lived challenge.
Most visitors never see OTCaptcha. Those who look automated face rising cost, and your team does not have to step in.
The small loader asks for a signed, short-lived challenge.
Background threads solve it without blocking the page.
The answer and signals are assessed, then a pass is issued.
Your backend checks the pass once, then continues.
Normal visitors. The browser solves a small proof-of-work in the background while signals are scored. There is nothing to click.
Suspicious traffic. A short hold on top of harder background work. It works with touch, mouse and keyboard.
Riskiest traffic. Slide the piece into place. Anyone who cannot drag, or misses three times, moves to a press and hold.
The invisible check is a small proof-of-work: the visitor's device solves it in background threads in a fraction of a second, measured on a laptop, while a bot farm pays for it on every attempt. During an attack the work doubles, then doubles again, and the hold is shown at a lower risk score. Try all three in your browser.
No single signal decides. Evidence adds up, and legitimate unusual setups are not blocked for one odd detail.
Two scores are kept for every attempt: one for the network it came from and one for the browser it claims to be. Each names the checks behind it, so a decision can always be explained.
New checks run in measuring mode first. They are recorded on real traffic and only start to count once they are known not to catch real visitors.
Markers left by browser automation tools.
Whether the claimed device matches how it behaves.
Hosting networks and rapidly repeating sources.
Whether time on the page and input look human.
The same network, device or near-empty browser profile coming back again and again.
A drag that is too even, too fast or too straight reads as a machine, not a hand.
Volume or suspicious spikes raise work to 2x, then 4x. Each level eases off after ten quiet minutes.
If our service is unreachable, your sign-ups continue. Blocking our domain alone does not skip the check.
Each pass works once and expires after five minutes.
When a visitor does see a check, it should look like part of your page. Four settings per site, applied the moment the box opens, with no change to your code.
Your brand colour on the fill, the handle and the tick. Colours that would be hard to read are refused.
From square to fully rounded, so the box matches your buttons.
Follow the visitor’s system setting, or fix one mode to match your page.
A small "Protected by OTCaptcha" line under the box. Hide it per site if you prefer.
A check that some people cannot pass is a check that costs you customers. The hold and the puzzle work with a keyboard and a screen reader, and anyone who cannot drag gets the hold instead. Read the full accessibility statement.
The hold works with the space bar or Enter. The puzzle piece moves with the arrow keys. Tab stays inside the box while it is open, Escape closes it, and focus returns to where it was.
The box is announced as a dialog. Controls carry labels, and status messages such as "Verified" are read out.
Animations and vibration are skipped when the device asks for reduced motion. On phones the box rises from the bottom of the screen, within easy reach of a thumb.
The box speaks the visitor's language, taken from the page: English, Spanish, Portuguese, Arabic, Hindi and Chinese. Arabic is laid out right to left.
The loader is about 12 KB gzipped, and the work happens off the main thread, so your page stays responsive. On the server side the service is built to lose a machine, or a whole location, without your form noticing.
The service runs in Germany and Finland, behind two load balancers. If one location fails, traffic moves to the other by itself.
One-time passes live in a replicated store with automatic failover across three locations.
About 800 full sign-ups a second per server, measured on one 4-core server at 76% CPU. Capacity is added by adding servers.
Faults on our servers are reported to an error tracker. Those reports carry no IP addresses, tokens, headers or page content.
Solve times measured on an Apple M3 Max across five desktop browsers ranged from about 30 to 130 ms with background workers. No phone has been measured yet; weak phones are the reason the work is raised in steps rather than all at once.
The service needs to see enough to tell a bot from a person, and no more. The security page lists what is processed in full.
Time, site, which check ran, the outcome, the scores and the signals that contributed. Network and device identifiers are stored as salted hashes that change every day.
Form contents, passwords, e-mail addresses, cookies or anything typed on your page.
Detailed records are kept for 90 days, then deleted. Daily totals without identifiers are kept so that long-term trends survive.
Each record names the version of the scoring that produced it, so a change in the rules can never be mistaken for a change in your traffic.
Protection you can read about. Nothing in the reports identifies a visitor.
Traffic, outcomes, attacks, new suspicious networks and solve times, once a week.
Every automatic escalation is kept as one event: when it started, what raised it, which networks and countries were involved, and when it ended.
How many visitors who saw a hold or a puzzle finished it, gave up, or switched to the other check. Visitors who leave never reach your server, so this is the only place they show up.
A site that shows the check but never confirms passes on its server is unprotected. We name it, so an integration gap is noticed before an attacker does.