About ilovecaptcha
Last updated · Written and maintained by the ilovecaptcha team
What is this project?
ilovecaptcha is an API that solves CAPTCHA challenges automatically, aimed at developers whose automated work stops at a verification widget. It targets 15 CAPTCHA and bot-verification systems behind a single REST/JSON interface, so a caller does not have to write and maintain one integration per vendor. The project is in development: the domain, the site and the infrastructure are live, the public API is not.
Who is it built for?
Three groups, in practice, listed below. What they have in common is that no human is sitting in front of the screen when the challenge appears, so a verification widget stops the work outright rather than slowing it down.
- Automated testing — end-to-end suites that hit a verification widget in a signup, login or checkout flow and stop there.
- Availability and accessibility monitoring — scripted journeys that must reach the page behind the challenge to measure anything at all.
- Public data collection — reading pages a site publishes openly, within the terms that site sets out.
Where does the project stand today?
The page you are reading is a holding page: it documents the intended scope honestly rather than announcing a product that cannot yet be used. Nothing is published that has not been measured, and those numbers will appear here when they exist, not before.
- Live — domain, DNS, TLS certificate and these pages, since 1 August 2026.
- Not open — the public API, the account area and the technical documentation.
- Not published — pricing, average solving time and success rate, none of which has been measured on a production engine.
Why does an API like this exist?
Because verification widgets now sit on the path of work that has no human behind it, and because the challenge itself is contested. According to the W3C Accessible Platform Architectures Working Group, the interactive task at the heart of a CAPTCHA excludes part of the population outright.
“The very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users.”
Where is the line drawn?
Between work you are entitled to run and work you are not. A test suite exercising an application its own team owns is not the same thing as an attempt to defeat a protection on someone else's service. The context above explains why these widgets are contested; it is not a justification for bypassing a control someone deliberately put in place. The acceptable use rules published with the API draw that line explicitly.
Which sources are quoted here?
Public, dated, primary ones only: the standards body that documented the accessibility problem, and the reference documentation each vendor publishes for its own challenge. Nothing is quoted from a secondary summary.
- W3C Accessible Platform Architectures Working Group, Inaccessibility of CAPTCHA, Group Draft Note, 16 December 2021.
- Cloudflare, Announcing Turnstile, a user-friendly, privacy-preserving alternative to CAPTCHA, 28 September 2022.
- Amazon Web Services, AWS WAF Captcha is now generally available, June 2022, and the AWS WAF CAPTCHA developer guide.
- Google, reCAPTCHA v2 developer documentation.
- Intuition Machines, hCaptcha documentation.
- GeeTest, GeeTest documentation.
Who writes the content?
The ilovecaptcha team writes and maintains these pages. Figures taken from outside sources are attributed inline and listed in the Sources section of the home page, with the publication date of each document, so any claim can be traced back and checked. Pages carry a visible last updated date; when a fact changes, the date changes with it.