DEV Community: DBC

Cloudflare Turnstile Solver: Wire Death By Captcha into Your Automation

DBC — Wed, 21 Oct 2026 10:41:27 +0000

Cloudflare Turnstile verifies visitors without showing a puzzle: no
image grid, no checkbox to click — the widget collects signals in the
background and hands the page a token when it trusts the session. That
design is what makes it strong, and it is also where an automated run
stalls: there is nothing to click, so there is nothing for a script to
replay. This guide wires Death By Captcha (DBC) into that gap with the
token flow: your script reads the widget's parameters from the page,
requests a solution from the DBC API, places the token where the widget
expects it, and the site verifies the session exactly as it would for a
browser that passed on its own.

Everything below runs against the public Turnstile demo that the
official samples point at, so you can test the loop end to end before
aiming it at your own target. The API calls are the ones from the
official client examples — nothing here is invented. The shape is the
same one the Playwright and Selenium integrations use: extract,
request, inject, submit, verify.

Why the token flow

Turnstile has one integration shape worth building on: the token. The
challenge is evaluated on the provider's side and comes back as a
single-submission response token; your script places it in the page and
continues. That is what keeps the flow headless and CI-safe — nothing
in your driver has to imitate a human pointer, because Turnstile never
asks for one.

The same shape repeats across the supported set — the payload fields
change, the loop does not.

What you need

A DBC account — solutions are paid from your account balance, so check the balance before decoding: https://deathbycaptcha.com/register
Python 3 or Node.js
Credentials in environment variables, never in the code:

export DBC_USERNAME=your_username
export DBC_PASSWORD=your_password

Install

Python (the integration guide's line):

pip install deathbycaptcha-official

Node.js:

npm install deathbycaptcha-lib

The solve call

Turnstile is type=12 with a turnstile_params payload. The payload
carries:

sitekey — the widget's public key, read from the page
pageurl — the exact URL the widget is rendered on
proxy and proxytype — the same proxy your traffic uses, so the solve context matches the submit context

Aligning the proxy and the page URL with the request that submits the
token is the single biggest reliability lever: a token solved in one
context and submitted from another is the classic source of repeated
retries. The official Turnstile page makes the same point first — keep
the solve and submit flow synchronized, use bounded polling and a
retry policy, and validate in staging before scaling volume.

The full flow in Python

Adapted from the official runnable in the Python client repository
(examples/example.Turnstile.py):

import json
import os

import deathbycaptcha

USERNAME = os.getenv("DBC_USERNAME")
PASSWORD = os.getenv("DBC_PASSWORD")
PAGE_URL = "https://clifford.io/demo/cloudflare-turnstile"
SITEKEY = "0x4AAAAAAAGlwMzq_9z6S9Mh"

client = deathbycaptcha.HttpClient(USERNAME, PASSWORD)


def solve_turnstile(sitekey, page_url):
    payload = {
        "proxy": "http://user:password@127.0.0.1:1234",
        "proxytype": "HTTP",
        "sitekey": sitekey,
        "pageurl": page_url,
    }
    result = client.decode(type=12, turnstile_params=json.dumps(payload))
    return result.get("text") if result else None


# optional pre-flight: check the balance once, not per captcha
# client.get_balance()

token = solve_turnstile(SITEKEY, PAGE_URL)
if not token:
    raise SystemExit("no solution yet - retry with backoff")
print(token)

The structure is the official sample's: build the payload, pass it to
decode with type=12, and read the token back from the text field
of the response. The socket client takes the same decode call if you
prefer the persistent transport.

The same flow in Node.js

Adapted from the official runnable in the Node.js client repository
(examples/example.Turnstile.js):

const dbc = require('deathbycaptcha-lib');

const USERNAME = process.env.DBC_USERNAME;
const PASSWORD = process.env.DBC_PASSWORD;
const PAGE_URL = 'https://clifford.io/demo/cloudflare-turnstile';
const SITEKEY = '0x4AAAAAAAGlwMzq_9z6S9Mh';

const client = new dbc.HttpClient(USERNAME, PASSWORD);

function solveTurnstile(sitekey, pageurl) {
  const turnstile_params = JSON.stringify({
    proxy: 'http://username:password@proxy.example:3128',
    proxytype: 'HTTP',
    sitekey: sitekey,
    pageurl: pageurl,
  });
  return new Promise((resolve, reject) =>
    client.decode(
      { extra: { type: 12, turnstile_params: turnstile_params } },
      (captcha) =>
        captcha && captcha.text
          ? resolve(captcha.text)
          : reject(new Error('no solution yet - retry with backoff'))));
}

solveTurnstile(SITEKEY, PAGE_URL).then(console.log).catch(console.error);

The Node.js client takes the same two fields under an extra object,
and the token comes back on captcha.text. It is the same call shape
the Python client uses, so the two stay in lockstep.

Placing the token in the page

The token is not the end of the job — it has to land where the widget
expects it. Turnstile exposes the solved response through a hidden form
field named cf-turnstile-response and, on pages that read the token
in JavaScript, through the widget's own success callback. Your driver
does one of two things with the solved token:

Pages that submit a form: write the token into the cf-turnstile-response field so the normal submit carries it.
Pages that read the token from JavaScript: pass the token into the widget's success callback so the page continues on its own.

Keep this step synchronized with the solve call: the same proxy, the
same page URL, and no long gap between the solve finishing and the
token being submitted.

Beyond Turnstile

The same loop covers the rest of the supported set. reCAPTCHA v3,
GeeTest, DataDome, plus image and text captchas follow their own
documented payloads — each CAPTCHA type is routed to a model
specialized for that type. The official Python client ships a runnable
sample per type under examples/, and the Node.js client mirrors
them.

On the library side, official clients cover Python, Node.js, C#, Java,
.NET, Go, C, C++ and Perl, and the browser extensions for Chrome/Brave
and Firefox cover the no-code path for manual sessions.

Fitting it into a bigger run

The official samples are built for pipelines, and the Turnstile page's
rollout guidance fits the same habits:

Align proxy and verification context to reduce mismatches.
Use bounded polling and a retry policy for predictable runs.
Validate in staging before scaling request volume.
Keep one code path for local and CI — only flags change, never the flow.

Notes that save runs

Credentials stay in environment variables in both official samples.
The balance call is a pre-flight, not part of the solve loop: check it once at pipeline start, not per captcha.
The payload's pageurl must match the page the token is submitted from — that is the context sync the official page names first.
End with the honest branch: no solution -> retry with backoff. Wire that branch before production.
Fail loudly on timeouts instead of letting a stalled challenge hang the pipeline.

Docs and sign-up

API reference and client links: https://deathbycaptcha.com/api
Turnstile solver page: https://deathbycaptcha.com/turnstile-solver
Python API integration guide: https://deathbycaptcha.com/python-captcha-api
Balance and pricing: https://deathbycaptcha.com/user-pay
Create an account: https://deathbycaptcha.com/register

Selenium Captcha Solver: Wire Death By Captcha into Your Test Runs

DBC — Fri, 16 Oct 2026 11:54:38 +0000

Selenium turns a browser script into a test that acts like a
user: it clicks, types, waits, asserts. A captcha challenge is
where that illusion breaks — the run stalls on a widget that no
amount of click emulation reliably dismisses. This quickstart
wires Death By Captcha (DBC) into a Selenium script with one
repeatable pattern: the script reads the challenge parameters
from the page, requests a solution from the DBC API, injects the
token back into the page, and continues — the site verifies it
exactly as if the widget had been solved in a real browser.

Everything below runs against Google's own public reCAPTCHA demo,
so you can test the whole loop end to end before pointing it at
your own target. The calls are the ones from the official
samples — the Selenium integration page and the runnable
examples that ship in the Python and Node.js client
repositories — nothing here is invented. The shape is the same
one the Playwright integration uses: extract, request, inject,
submit, assert.

Why the token flow

reCAPTCHA v2 has two integration shapes: replaying the interactive
challenge inside your browser context, or the token flow used here.
The token flow solves the challenge on the provider's side and returns
a response token that is valid for one submission; your script injects
it and moves on. That is what makes it work headless and inside CI:
nothing in your driver has to mimic a human pointer, and the page
sees a normal solved widget.

The same shape repeats across the supported set — the payload fields
change, the loop does not.

What you need

A DBC account — solutions are paid from your account balance, so check the balance before decoding: https://deathbycaptcha.com/register
Python 3 or Node.js, plus Selenium and Firefox or Chrome (Selenium 4 resolves the driver on its own, so the browser is the only extra install)
Credentials in environment variables, never in the code:

export DBC_USERNAME=your_username
export DBC_PASSWORD=your_password

Install

Python (the integration page's line):

pip install selenium deathbycaptcha-official

Node.js:

npm install selenium-webdriver deathbycaptcha-lib

The full flow in Python

Adapted from the official runnable in the Python client
repository (examples/deathbycaptcha-python-selenium):

import json
import os
import time

import deathbycaptcha
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.support.wait import WebDriverWait

USERNAME = os.getenv("DBC_USERNAME")
PASSWORD = os.getenv("DBC_PASSWORD")
DEMO_URL = "https://www.google.com/recaptcha/api2/demo"


def solve_captcha(payload):
    client = deathbycaptcha.SocketClient(USERNAME, PASSWORD)
    # optional pre-flight, both official samples do it:
    # client.get_balance()
    result = client.decode(type=4, token_params=json.dumps(payload))
    return result.get("text") if result else None


with webdriver.Firefox() as driver:
    driver.set_page_load_timeout(60)
    driver.get(DEMO_URL)

    # 1. extract the challenge parameters from the page
    element = WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((By.ID, "recaptcha-demo")))
    sitekey = element.get_attribute("data-sitekey")

    # 2. request the solution token from DBC (type 4 = reCAPTCHA v2)
    token = solve_captcha({"googlekey": sitekey, "pageurl": DEMO_URL})
    if not token:
        raise SystemExit("no solution yet - retry with backoff")

    # 3. inject the token back into the page
    driver.execute_script(
        "document.getElementById('g-recaptcha-response')"
        ".value = arguments[0]", token)

    # 4. submit and check the success element
    driver.find_element(By.ID, "recaptcha-demo-submit").click()
    time.sleep(2)
    print(driver.find_element(By.CLASS_NAME, "recaptcha-success").text)

Two details lifted straight from the official runnable: the
explicit WebDriverWait instead of blind sleeps for finding the
widget, and the page-load timeout so a stalled navigation fails
loudly instead of hanging the suite. The full script also switches
Firefox/Chrome and headless mode from environment variables.

The same flow in Node.js

Adapted from the official runnable in the Node.js client
repository (examples/selenium/recaptcha_v2_selenium.js):

const { Builder, until, By } = require('selenium-webdriver');
const { HttpClient } = require('deathbycaptcha-lib');

const USERNAME = process.env.DBC_USERNAME;
const PASSWORD = process.env.DBC_PASSWORD;
const DEMO_URL = 'https://www.google.com/recaptcha/api2/demo';

const client = new HttpClient(USERNAME, PASSWORD);

function decode(payload) {
  return new Promise((resolve, reject) =>
    client.decode({ extra: payload }, (solution) =>
      solution && solution.text
        ? resolve(solution.text)
        : reject(new Error('no solution yet - retry with backoff'))));
}

(async () => {
  const driver = await new Builder().forBrowser('firefox').build();

  try {
    await driver.get(DEMO_URL);

    // 1. extract the challenge parameters from the page
    const element = await driver.wait(
      until.elementLocated(By.id('recaptcha-demo')), 15000);
    const sitekey = await element.getDomAttribute('data-sitekey');

    // 2. request the solution token from DBC (type 4 = reCAPTCHA v2)
    const token = await decode({
      type: 4,
      token_params: JSON.stringify(
        { googlekey: sitekey, pageurl: DEMO_URL }),
    });

    // 3. inject the token back into the page
    await driver.executeScript(`
      const token = arguments[0];
      const textarea = document.getElementById('g-recaptcha-response');
      textarea.style.display = 'block';
      textarea.value = token;
      textarea.innerHTML = token;
      textarea.dispatchEvent(new Event('input', { bubbles: true }));
      textarea.dispatchEvent(new Event('change', { bubbles: true }));
      if (window.___grecaptcha_cfg && window.___grecaptcha_cfg.clients) {
        const clients = window.___grecaptcha_cfg.clients;
        for (const clientKey of Object.keys(clients)) {
          const item = clients[clientKey];
          for (const key of Object.keys(item)) {
            const entry = item[key];
            if (entry && typeof entry.callback === 'function') {
              entry.callback(token);
              return true;
            }
            if (entry && entry.W && typeof entry.W.callback === 'function') {
              entry.W.callback(token);
              return true;
            }
          }
        }
      }
      return true;
    `, token);

    // 4. submit and wait for the success element
    await driver.findElement(By.id('recaptcha-demo-submit')).click();
    await driver.wait(
      until.elementLocated(By.className('recaptcha-success')), 15000);
    console.log('success');
  } finally {
    await driver.quit();
  }
})();

The page-side steps are identical to the Python version; the
injection block goes one step further and fires the widget's own
callback from the reCAPTCHA config tree — that is what wakes the
page up when setting the textarea alone is not enough. The full
runnable wraps the same logic in an exported function with the
browser and timeouts read from environment variables.

Beyond reCAPTCHA v2

The same loop covers the rest of the supported set. Turnstile is the
same call with a different type and payload name — type=12 with a
turnstile_params payload carrying sitekey and pageurl — and
reCAPTCHA v3, GeeTest, DataDome, plus image and text captchas follow
their own documented payloads: each CAPTCHA type is routed to a model
specialized for that type. The official Python client ships a runnable
sample per type under examples/.

Both clients default to the encrypted HTTPS transport and also ship a
socket transport for high-throughput production runs; the method names
stay the same, so moving between them later is a constructor change,
not a rewrite. The Python flow above already runs on the socket
client — same decode call the HTTPS transport serves.

On the library side, official clients cover Python, Node.js, C#, Java,
.NET, Go, C, C++ and Perl, and the browser extensions for Chrome/Brave
and Firefox cover the no-code path for manual sessions.

Fitting it into a bigger run

The official runnables are built for pipelines: browser choice,
headless mode and wait timeouts all come from environment
variables, and the Node.js sample extends its wait when it
detects CI so slow runners do not race the page. Keep three
habits from them:

One code path for local and CI — only flags change, never the flow. Inconsistent challenge handling across environments is how green suites start failing on runners.
Explicit waits around the widget and the success element; a sleep is only safe where the official sample uses it as a short demo pause, not as synchronization.
Fail loudly on timeouts (page-load timeout, element waits) instead of letting a stalled challenge hang the pipeline.

Notes that save runs

Credentials stay in environment variables in both official samples — the Node.js one refuses to start with the literal placeholder values still in place.
The balance call is a pre-flight, not part of the solve loop: check it once at pipeline start, not per captcha.
Sitekey extraction has a fallback in the official Python script (attribute read, then a script-side read) because widgets render differently across drivers — keep both.
Both samples end with the same honest branch: no solution -> retry with backoff. Wire that branch before production; a retry policy is what separates flaky solves causing intermittent test failures from a pipeline that recovers.
Treat a missing success element as a first-class outcome (the Python sample catches it and reports it) — silent passes are how broken flows ship.

Docs and sign-up

The same shape applies to the other runners: the integration
pages for Playwright and Puppeteer walk the same
request-and-inject loop, and the per-type examples document
every payload field the clients accept.

API reference and client links: https://deathbycaptcha.com/api
Selenium integration page: https://deathbycaptcha.com/selenium-captcha-solver
Balance and pricing: https://deathbycaptcha.com/user-pay
Create an account: https://deathbycaptcha.com/register

Playwright Captcha Solver: Wire Death By Captcha into Your Automation

DBC — Wed, 14 Oct 2026 11:49:53 +0000

Playwright makes browser automation fast — until a captcha challenge
stops the run mid-flow. This quickstart wires Death By Captcha (DBC)
into a Playwright script with one repeatable pattern: the script reads
the challenge parameters from the page, requests a solution from the
DBC API, injects the token back into the page, and continues — the
site verifies it exactly as if the widget had been solved in a real
browser. No click emulation, no brittle waits on challenge dialogs.

Everything below runs against Google's own public reCAPTCHA demo, so
you can test the whole loop end to end before pointing it at your own
target. The calls are the ones from the official runnable examples —
nothing here is invented. Beyond the client's few methods (balance,
upload, poll) there is no extra SDK surface to learn: the whole
integration is one request-and-inject cycle you can read in a single
sitting and reuse everywhere the same challenge type shows up.

Why the token flow

reCAPTCHA v2 has two integration shapes: replaying the interactive
challenge inside your browser context, or the token flow used here.
The token flow solves the challenge on the provider's side and returns
a response token that is valid for one submission; your script injects
it and moves on. That is what makes it work headless and inside CI:
nothing in your browser has to mimic a human pointer, and the page
sees a normal solved widget.

The same shape repeats across the supported set — the payload fields
change, the loop does not.

What you need

A DBC account — solutions are paid from your account balance, so check the balance before decoding: https://deathbycaptcha.com/register
Python 3 or Node.js, plus Playwright
Credentials in environment variables, never in the code:

export DBC_USERNAME=your_username
export DBC_PASSWORD=your_password

Install

Python:

pip install deathbycaptcha-official playwright
playwright install

Node.js:

npm install deathbycaptcha-lib playwright

The full flow in Python

import json
import os
import time

import deathbycaptcha
from playwright.sync_api import sync_playwright

DEMO_URL = "https://www.google.com/recaptcha/api2/demo"

client = deathbycaptcha.HttpClient(
    os.environ["DBC_USERNAME"], os.environ["DBC_PASSWORD"]
)


def solve_recaptcha_v2(page_url, sitekey, timeout=120):
    """Request a reCAPTCHA v2 token (API type=4), poll until solved."""
    if not client.get_balance():
        raise SystemExit("no balance - top up before decoding")
    upload = client.upload(
        type=4,
        token_params=json.dumps(
            {"googlekey": sitekey, "pageurl": page_url}
        ),
    )
    cid = upload["captcha"]
    deadline = time.time() + timeout
    while time.time() < deadline:
        time.sleep(0.5)
        detail = client.get_captcha(cid)
        if isinstance(detail, dict) and detail.get("text"):
            return detail["text"]
    raise TimeoutError("no solution; retry with backoff")


with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto(DEMO_URL, timeout=60000)

    # 1. read the challenge parameters from the page
    sitekey = page.get_attribute("#recaptcha-demo", "data-sitekey")

    # 2. request the solution token from DBC
    token = solve_recaptcha_v2(DEMO_URL, sitekey)

    # 3. inject the token and trigger the page's own callback
    page.evaluate(
        """(t) => {
            const el = document.getElementById('g-recaptcha-response');
            if (!el) return;
            el.style.display = 'block';
            el.value = t;
            el.dispatchEvent(new Event('input', { bubbles: true }));
            el.dispatchEvent(new Event('change', { bubbles: true }));
            const cfg = window.___grecaptcha_cfg;
            if (!cfg || !cfg.clients) return;
            for (const k of Object.keys(cfg.clients)) {
                const c = cfg.clients[k];
                for (const key of Object.keys(c)) {
                    const item = c[key];
                    if (item && typeof item.callback === 'function')
                        return item.callback(t);
                    if (item && item.W &&
                        typeof item.W.callback === 'function')
                        return item.W.callback(t);
                }
            }
        }""",
        token,
    )

    # 4. submit and wait for the page to report success
    page.click("#recaptcha-demo-submit")
    page.wait_for_selector(".recaptcha-success", timeout=15000)
    print("solved")
    browser.close()

Run it:

python playwright_dbc_quickstart.py

If the token is accepted, the script prints solved and exits 0. If
the challenge is not solved within the timeout it raises — a broken
integration fails loudly instead of hanging your pipeline. That
failure path is the runnable test: wire the script into CI as-is, or
drop the last three lines into a test runner and assert on the
success selector like any other page state.

What each step does:

get_balance() — confirm the account can pay for the job before submitting anything.
upload(type=4, ...) — type 4 is the reCAPTCHA v2 token API. The googlekey (the widget's site key) and pageurl (the exact URL where the challenge loads, path included) identify the challenge; the client polls get_captcha() until the token text arrives.
The token goes into the page's hidden response field and the page's own reCAPTCHA callback fires — from the site's point of view the widget was solved normally.
The submit click plus the success selector close the loop.

The same flow in Node.js

const { HttpClient } = require('deathbycaptcha-lib');

const client = new HttpClient(
  process.env.DBC_USERNAME, process.env.DBC_PASSWORD);

function solveRecaptchaV2(pageUrl, sitekey) {
  return new Promise((resolve, reject) =>
    client.decode(
      {
        extra: {
          type: 4,
          token_params: JSON.stringify(
            { googlekey: sitekey, pageurl: pageUrl }),
        },
      },
      (solution) => solution && solution.text
        ? resolve(solution.text)
        : reject(new Error('no solution yet - retry with backoff'))
    ));
}

The page-side steps — extract the sitekey, request the token, inject
it, trigger the callback — are identical to the Python version. The
official sample also checks the balance first, and the full runnable
script ships in the official Node.js client repository under
examples/playwright.

Beyond reCAPTCHA v2

On the library side, official clients cover Python, Node.js, C#, Java,
.NET, Go, C, C++ and Perl, and the browser extensions for Chrome/Brave
and Firefox cover the no-code path for manual sessions.

Fitting it into a bigger run

Nothing in the script has to run standalone. In a real scraper or test
suite the pattern sits next to the action that gets blocked: navigate,
detect the challenge widget on the page, call the solve step, inject,
continue. Because the token is requested only when a challenge is
actually present, unblocked runs submit no jobs at all, and the
balance check doubles as a first failure gate for scheduled jobs.
Keep the solve function in one shared module and every Playwright
entrypoint in the project can call it without copy-paste.

Notes that save runs

Keep the solve path and the submit path on the same network. The token is verified from the IP that submits it, and a mismatch between that address and the context the challenge was solved in is the usual cause of rejected tokens. If your automation already goes through a proxy, pass it in the same params payload (proxy + proxytype) so both hops align.
Retry with backoff on an empty result. "No solution yet" is transient by design — the official examples retry instead of failing immediately.
Set explicit timeouts at every hop: navigation, upload, polling, page waits. Silent stalls are how one flaky challenge turns into a hung pipeline.

Docs and sign-up

The same shape applies to the other runners: the integration pages
for Selenium and Puppeteer walk the same request-and-inject loop, and
the per-type FAQ documents every payload field the clients accept.

API reference and client links: https://deathbycaptcha.com/api
Playwright integration page: https://deathbycaptcha.com/playwright-captcha-solver
Balance and pricing: https://deathbycaptcha.com/user-pay
Create an account: https://deathbycaptcha.com/register

Best Captcha Solvers 2026: Comparison

DBC — Fri, 09 Oct 2026 14:18:53 +0000

If you are picking a captcha solving service for automation, web
scraping, or browser testing in 2026, the shortlist usually looks
the same: a handful of long-running APIs that solve reCAPTCHA,
Cloudflare Turnstile, GeeTest, and image captchas and return a
token or text answer your script can use. This article is a real
comparison of the five services that show up in those shortlists:
shared criteria, a side-by-side matrix built from each provider's
public documentation, and a per-provider analysis — so you can
re-rank the table against your own priorities.

How we compared

Six criteria, applied to every provider:

Modern captcha type coverage — reCAPTCHA (v2/v3/Enterprise), Cloudflare Turnstile, GeeTest, and image captchas.
Official client libraries — languages each provider ships officially, not community wrappers.
API and documentation — a clear HTTP flow (send the challenge, receive the solution) with real docs.
Pricing model — pay-as-you-go with published rates, plus what our own testing showed about advertised vs charged amounts (see the matrix note ¶).
Integration fit — Selenium / Playwright / Puppeteer workflows and browser extensions.
Availability — what each service publishes about uptime (status page, claims) versus what a real solve does at your hour; the DBC API accepts requests 24/7.

Method: every capability cell was checked against the provider's
own public docs on 2026-10-09; the pricing (¶) and availability (†)
notes are our own testing. Features move fast — re-check before you buy.
Scope: only the four modern types above; legacy challenge types
are out of scope. Ranking note: this is DBC's own disclosed
comparison, DBC is weighted first on integration breadth, and the
matrix is here so you can disagree with that weighting.

Side-by-side matrix

Provider	Types*	Clients	Extension	Availability	Pricing
Death By Captcha	4 of 4	9	Chrome, FF	24/7	deathbycaptcha.com/user-pay
2Captcha	4 of 4	7	Chrome	verify†	not clear¶
Anti-Captcha	4 of 4	10	—	verify†	rate page
CapSolver	4 of 4	SDKs	Chrome, FF	verify†	rate page
CapMonster Cloud	4 of 4	5	Chrome, FF	verify†	rate page

* Types = the four compared modern types — reCAPTCHA (v2/v3/Enterprise), Cloudflare Turnstile, GeeTest, and image captchas. All five cover 4 of 4, verified in each provider's public docs on 2026-10-09. Parity on types is the finding here.
Clients = official client languages published by each provider: DBC 9 (Python, Node.js, C#, Java, .NET, Go, C, C++, Perl); 2Captcha 7 (Python, Java, C#, C++, JavaScript, Ruby, PHP); Anti-Captcha 10 (Python, Node.js, Go, PHP, Java, Kotlin, C#, C++, Rust, Ruby); CapSolver ships SDKs plus community libraries without one fixed language list; CapMonster Cloud 5 (C#, Python, JS, Go, PHP).
FF = Firefox; the DBC extension also runs on Brave.
† Availability: the DBC API accepts requests 24/7. All four others publish a status page and uptime-style claims (checked 2026-10-09 — e.g. "99.9% uptime" and "uptime since 2007" appear in their marketing). Our own testing (October 2026) saw the opposite: a status page showed the service operational while a real solve request failed. Treat any "operational" badge as a starting point, not proof — verify with a live solve at your target hour.
¶ Pricing: all five publish pay-as-you-go rates. With 2Captcha, our own testing (October 2026) hit a mismatch between the rate advertised on their site and the amount actually charged — we mark them "not clear": verify for yourself with a small run before committing. We quote no figures here; read current rates on each provider's rate page.

1. Death By Captcha (DBC)

Death By Captcha (DBC) is a reliable captcha solver API for
automation, web scraping, and browser workflows, with official
client libraries, browser extensions, and support for modern
captcha types. Against the criteria:

Types: all four covered — each CAPTCHA type is routed to a model specialized for that type.
Clients: nine official ones (Python, Node.js, C#, Java, .NET, Go, C, C++, Perl), covering both application stacks and systems languages (C, C++, Perl) in one official set.
Extension: Chrome and Firefox stores; the Chrome build also runs on Brave.
Availability: the API accepts requests 24/7.
Workflow: official examples for Selenium, Playwright, and Puppeteer — send the challenge (type, page URL, sitekey), get the solution back, inject the token into your run.
Docs and pricing: public API docs, public rate page, pay-as-you-go.

Start with the API docs, check
the rate page for pricing,
and create an account.

2. 2Captcha

A long-running service with a wide HTTP API and seven official
client libraries (Python, Java, C#, C++, JavaScript, Ruby, PHP).
All four compared types are covered, the official extension lives
in the Chrome store, and the docs ship ready-made code examples
for scraping scripts. Trade-off vs the rest of this table:
Firefox users are not covered by an official extension.

3. Anti-Captcha

The most developer-facing of the five: a documentation-first API
with an apidoc, tutorials, and the widest official client list
here — ten languages (Python, Node.js, Go, PHP, Java, Kotlin, C#,
C++, Rust, Ruby). All four compared types are covered. Trade-off:
it is API-only — no browser extension appears on their public
surface, so everything runs through your own code.

4. CapSolver

A newer-generation, task-based API covering all four compared
types plus adjacent protections (AWS WAF, Cloudflare challenge).
Its weight sits in integration: SDKs with community libraries,
hooks for Selenium, Puppeteer, Playwright and n8n, an official
Chrome/Firefox extension, and 2026-era agent integrations (MCP
and agent tooling). Docs are organized as guides per captcha type.

5. CapMonster Cloud

A straightforward JSON request/response API with five official
SDKs (C#, Python, JS, Go, PHP) and official Chrome and Firefox
extensions. All four compared types are covered. It is the
simplest of the five to start with if one of those five languages
fits your stack; teams outside them lean on community libraries.

How to choose

Start from the matrix: if a provider misses a type you need or your language, it is out.
Check the official client for your stack — Python and Node.js cover most teams, but on Go, .NET, C or Rust the lists diverge fast.
Read the docs before signing up: the send-solution flow has to fit your run loop cleanly.
Test on your own targets first: one integration, small batches, measure solve quality against your real sites.
Compare pricing on each provider's rate page — figures change, and verify the actual charge with a small run: at least one provider here billed us differently than advertised.
Verify availability with a live solve at your own target hour: in our testing, a status badge showed "operational" while a real request failed.

Bottom line

On the four modern types the market treats as table stakes, all
five services are effectively at parity — so the real decision is
about clients, docs, extensions, and workflow fit, which is what
the matrix and the notes above spell out. Our own weighting puts
Death By Captcha (DBC) first for integration breadth: nine
official clients, extensions for both browser families, 24/7 API
availability, official Selenium/Playwright/Puppeteer examples,
and typed-model routing behind one API.