Captcha Solving Services for Web Scraping: 2026 Buyer's Guide

The first time a scraping project hits a captcha wall, the reflex is predictable: search for a solver, pick the cheapest one with a tolerable API, wire it in, move on. That works. It also quietly sets your unit economics for the next two years, because the invoice from a captcha solving service is not really a bill for solving captchas. It is a bill for how detectable your crawler is.

I have watched two teams pull the same retail catalogue at almost identical volume. One spent about forty dollars a month on solves. The other cleared two thousand. Same target, same page count, same vendor, same month. Everything that mattered happened upstream of the solver: proxy quality, session reuse, and whether the client they drove looked anything like a browser a human would use.

So this guide does two jobs at once. It is an honest buyer's guide to captcha solving services for web scraping — the categories, the real prices, the things that break at 3 a.m. in production, and how to run a bake-off that tells you the truth instead of the vendor's marketing page. And it is a reduction guide, because every challenge you never trigger is a solve you never pay for, a second of latency you never wait out, and a retry branch you never have to write.

What you are actually buying

The market looks crowded, but there are only four delivery models underneath the branding. Knowing which one you are buying tells you more about how it will behave than any accuracy claim.

Human solving farms

Real people, usually in low-wage labour markets, sitting in front of a queue of challenge images. You submit a job over an API, a worker clicks the fire hydrants, you get an answer back. 2Captcha and Anti-Captcha built this category and their API shape became a de facto standard that half the market now clones.

Humans are slow — ten to forty seconds is normal for an image grid — and the cost per solve is genuinely low. Their real advantage is generality. When a target rolls out a challenge art style nobody has trained a model on, a human still solves it on day one. Machine solvers need a week and a dataset.

Automated ML solvers

CapSolver, CapMonster Cloud and their peers run classifiers and, for token-based challenges, headless solving infrastructure. Latency drops to three to eight seconds and per-unit prices are often half the human farms. Reliability is bimodal: excellent on the challenge types they have trained hard on, sharply worse on anything unusual. Accuracy figures on a vendor site are averages across their whole traffic mix, which tells you almost nothing about your particular target.

Solver browser extensions

The same vendors ship extensions that sit inside a live browser session, spot a widget in the DOM, solve it, and fill the response field. This is the model that fits an antidetect browser workflow best, because the challenge is solved inside the same session, with the same cookies, the same TLS stack and the same exit IP that will submit the form. Fewer moving parts means fewer mismatch failures — more on why that matters below.

Managed unblockers and scraping APIs

Bright Data Web Unlocker, Oxylabs Web Unblocker, ZenRows, ScrapingBee and friends. You do not see the captcha at all. You send a URL, they handle proxies, browser emulation, challenge handling and retries, and you get HTML back. You pay per successful request rather than per solve.

This is the highest price per page by a wide margin and the lowest engineering cost by an equally wide margin. For a research project, a spiky one-off, or a target that is genuinely hostile, it is often the correct answer even though it looks expensive on a spreadsheet.

The challenge types you will actually meet

Buying a solver without knowing which system you are up against is how teams end up paying for a service that structurally cannot help them.

reCAPTCHA v2

The checkbox, and the image grid behind it. The solver returns a g-recaptcha-response token that you inject into the form before submitting. Tokens live about two minutes and are single-use. This is the best-supported challenge in the entire market; every vendor handles it and prices are commoditised.

reCAPTCHA v3

No challenge, no checkbox. The script scores the session from 0.0 to 1.0 and hands the score to the site, which sets its own threshold. Google's own reCAPTCHA v3 documentation is clear that the score is advisory and site-specific, which is exactly why solvers struggle here: they can mint a token, but they cannot guarantee the score attached to it. Score quality tracks IP reputation and cookie history far more than anything a vendor can sell you. If your target uses v3 with a strict threshold, the fix is upstream, not downstream.

hCaptcha

Structurally similar to v2 with an h-captcha-response token. Enterprise deployments add rqdata, a signed blob that binds the challenge to the session — if your solver does not accept and return rqdata, enterprise hCaptcha will reject every token it produces and you will spend an afternoon convinced the vendor is broken.

Cloudflare Turnstile

Returns cf-turnstile-response. Widely supported now. The trap is that Turnstile is frequently deployed alongside the Cloudflare managed challenge interstitial, and those are different animals. The interstitial is a JavaScript and proof-of-work gate that inspects your TLS handshake and browser environment; it does not have a token a solving service can mint. Cloudflare's Turnstile docs describe the widget; the interstitial is bot management, and you beat it by looking legitimate, not by buying solves.

Arkose Labs FunCaptcha

Rotating objects, matching icons, small puzzle games. Used by several large consumer platforms. Solvable, but two to ten times the price of reCAPTCHA and with meaningfully worse success rates. Budget accordingly.

GeeTest v3 and v4

Slider and puzzle challenges, common on gaming, ticketing and Chinese-market sites. v4 added behavioural telemetry that some cheap solvers still handle badly.

DataDome, HUMAN (PerimeterX), Kasada, AWS WAF

These are bot management platforms that sometimes present something captcha-shaped. Treat a DataDome block as a fingerprint and network problem with a captcha painted on the front. Solving the visible widget while your TLS fingerprint still screams Python will get you blocked again on the next request, and you will have paid for the privilege.

The general point: the history of CAPTCHA is a slow migration from puzzles that test perception toward systems that score behaviour and environment. Vendors that sell you a solve for the puzzle cannot sell you a solve for the score.

How token solving actually works in production

The documentation makes this look like a two-line integration. It is, until it isn't.

The basic flow: you extract the sitekey from the page, send it with the page URL to the solver, poll for a result, get a token, inject it into the form field, submit. Where teams lose days is in the binding rules.

A solved token is often bound to the environment that solved it. For plain reCAPTCHA v2 the token is usually not IP-bound, so a proxyless solve works fine. For v3, for enterprise variants of v2 and hCaptcha, and for Turnstile with client data, the token is frequently validated against the IP, user agent and cookie state of the session that requested it. If the solver used their own datacentre IP in Frankfurt and you submit from a residential IP in Ohio with a different user agent string, verification fails and you are debugging a phantom.

The fix is to run the solver in proxy mode: pass your exact proxy credentials and your exact user agent along with the job. It costs slightly more per solve at some vendors and adds a few seconds of latency. It also turns a 40 percent rejection rate into a 3 percent one.

Tokens expire. Roughly 120 seconds for the Google family. If your pipeline solves a batch of challenges and then queues the submissions behind a rate limiter, half of them will be dead on arrival. Solve as late as possible in the request path, not as early as convenient in the code.

Tokens are single-use. Retrying a failed submission with the same token is a guaranteed failure and a very common bug. Your retry logic must re-solve.

The solver itself will fail. Plan for four distinct outcomes, not two: solved and accepted, solved and rejected by the site, solver timeout, and solver-side error or capacity 429. Each needs different handling. Blanket-retrying a rejected token is how a bill triples overnight.

Measure rejection, not just solve rate. Vendors report the percentage of jobs they answered. What you care about is the percentage of answers the target accepted. Those two numbers can differ by thirty points and only one of them is on your dashboard by default.

The cost math nobody puts on the pricing page

Here is a model for a mid-sized crawl — one million pages a month against a moderately protected target — under four different upstream setups. The unit prices are mid-market 2026 rates.

Two things jump out. First, the spread between the worst and best in-house setup is roughly 24×, and none of that difference came from the solver — it came from how the client presented itself. Second, the managed API is an order of magnitude more expensive at this volume, and it is still the right call for a team of two who would otherwise spend three engineer-months building the other three rows.

The number to track is not cost per solve. It is cost per successfully extracted record, with proxy bandwidth, solver fees, compute and retry waste all in the numerator. A solver that is 30 percent cheaper per unit but rejected twice as often is more expensive, and only that metric shows it.

One more line item people forget: latency has a cost. If your p95 solve takes 25 seconds and you hold a browser session open the whole time, you are paying for concurrency you cannot use. At scale, that idle-worker cost sometimes exceeds the solve fees themselves.

Your captcha rate is a fingerprint problem first

Every hour spent making your client look ordinary pays for itself many times over in solver fees. The signals that push a session toward a challenge are well known and mostly cheap to fix.

Automation tells. navigator.webdriver set true, the Chrome DevTools Protocol attached with Runtime.enable called, missing plugin arrays, permission APIs behaving oddly under headless. Any one of these on its own is a hint; three together is a verdict.

Environment inconsistency. A user agent claiming Windows 11 while the platform string says Linux. Client Hints that disagree with the UA string — MDN's reference on the User-Agent header is worth a careful read, because Client Hints are now the primary channel and a stale UA-only spoof is trivially caught. A timezone of Europe/London on an IP that geolocates to São Paulo. Screen dimensions no shipping device has ever had.

Rendering gaps. No WebGL, or WebGL reporting SwiftShader when the UA claims a consumer laptop. Canvas output that is byte-identical across a thousand sessions, which is arguably a stronger signal than a unique value would be. The EFF's Cover Your Tracks is still the fastest way to see how loud your setup is before you point it at a real target.

Transport-layer mismatch. Your TLS handshake and HTTP/2 frame ordering form a fingerprint that has nothing to do with JavaScript. A Python client sending a perfect Chrome user agent has a JA4 signature that is not Chrome, and bot management platforms have checked that for years.

If that list is unfamiliar territory, start with browser fingerprinting explained for beginners and then work through the practical side in how to change browser fingerprint. Fixing these is not a fringe optimisation. It is the single highest-leverage thing you can do to your solver bill.

Proxies: the other half of the equation

A perfect fingerprint on a burnt IP still gets challenged. Proxy strategy deserves the same rigour.

Datacentre IPs are cheap, fast, and flagged by ASN on any target that cares. ISP proxies give you residential-looking ASNs with datacentre stability and are the sweet spot for most commercial scraping. True residential rotates through real consumer connections and costs several dollars a gigabyte. Mobile carrier IPs sit behind CGNAT with thousands of real users sharing an address, which makes them extremely hard to block — and priced to match.

The operational details matter more than the tier. Use sticky sessions so one logical crawl session keeps one exit IP; rotating mid-session is a loud signal. Watch subnet-level burn, because targets block /24 ranges, not single addresses. Match your locale, timezone and Accept-Language to the exit country every single time. And keep per-ASN challenge-rate metrics, so you notice a pool degrading before your costs do.

The full version of that argument, including how to pair pools with profiles, is in the antidetect browser with residential proxies playbook. And if anyone on the team is still reaching for a VPN, this comparison settles it: one shared exit IP for every session is the opposite of what scraping at scale needs.

Reduce the volume before you buy anything

A short checklist that has never failed to cut challenge rates on a project I have worked on.

Look for the API first. An astonishing share of the pages people scrape with a headless browser are rendered from a JSON endpoint the page itself calls. Open the network tab. That endpoint is usually faster, more stable, more structured and far less protected than the HTML around it.

Persist sessions. A cookie jar that survives across runs means you solve once and ride that session for hours or days. Throwing away cookies after every request means re-earning trust every request. This is the largest single lever after fingerprinting.

Use conditional requests. ETag and If-Modified-Since turn a re-crawl into a stream of 304s. Free, polite, and invisible to challenge systems.

Do not fetch what you do not parse. Blocking images, fonts, media and analytics beacons cuts bandwidth by 60 to 80 percent — but block too aggressively and the absence of expected requests becomes its own signal. Block media and third-party analytics; leave the first-party JavaScript alone.

Shape concurrency per domain. Fifty parallel workers against one host is a burst pattern no human generates. Ten workers with jittered pacing often extract the same volume per day with a fraction of the friction.

Cache aggressively at the edge of your pipeline. Deduplicate URLs, normalise query strings, and stop re-crawling pages whose content hash has not moved in six weeks.

A checklist for evaluating vendors

Run this before you commit to anyone. It takes about three days.

• Test on your targets, not their demo. Pull 500 real challenges from the sites you actually crawl and replay them against two or three vendors simultaneously. Vendor-published accuracy is an average over someone else's traffic.
• Measure acceptance, not solve rate. Log whether the target accepted the token, not whether the vendor returned one.
• Check p50 and p95 latency. The tail is what sizes your worker pool.
• Confirm proxy passthrough. Can you supply your own proxy and user agent per job? For anything enterprise-tier, this is mandatory.
• Confirm coverage of your exact challenge. Enterprise hCaptcha with rqdata, Turnstile with client data, GeeTest v4 — ask specifically, not generically.
• Understand the refund policy. Do you pay for a solve the site rejected? Most vendors only refund their own reported failures.
• Check concurrency limits and burst behaviour. Many plans cap parallel jobs far below what a real crawl needs, and the overage pricing is where the margin lives.
• Prefer a 2Captcha-compatible API. It is the closest thing to a standard, and it makes switching vendors a config change rather than a sprint.
• Look at the status page history. Not the current status — the incident archive.
• Read the data handling terms. You are sending page URLs and sometimes screenshots to a third party. Know where that goes.

Where the solver belongs in your architecture

Four patterns, roughly in order of cost and control.

Pattern A: HTTP-first with token injection

An async HTTP client does the crawling. When a challenge appears, you extract the sitekey, call the solver, inject the token into the form POST, and continue. Cheapest per page and by far the fastest. Fails against anything that scores browser behaviour, because there is no browser to score.

Pattern B: Browser pool with a solver extension

Real browser instances, with a solver extension handling widgets in-session. Slower and heavier — figure 300 to 600 MB of RAM per instance — but it survives challenges that Pattern A cannot touch, and because everything happens in one session there are no IP or UA mismatch failures.

Pattern C: Managed unblocker

You write a URL fetcher and nothing else. Correct for small teams, hostile targets and anything where engineering time is scarcer than budget.

Pattern D: The escalation ladder

What mature pipelines actually run. Try the cheap HTTP path. On a challenge or a block, retry once through a different proxy pool. Still blocked, escalate that URL to the browser pool with a solver attached. Still blocked after that, route it to the managed API and log the domain for review. Roughly 85 percent of traffic clears at tier one at tier-one cost, and only the genuinely difficult remainder pays the premium. Track the tier distribution per domain — a target drifting from 90 percent tier-one to 40 percent is telling you something changed on their side before your error rate does.

Building this on Dual Login

Dual Login is an antidetect browser: many isolated browser profiles, each with its own consistent fingerprint, its own persistent data directory, and its own proxy. For Pattern B and Pattern D, that maps onto the problem almost exactly.

Profiles are durable identities. Cookies, localStorage and IndexedDB persist between runs in a per-profile data directory. A session that cleared a challenge on Monday is still trusted on Wednesday. Given that session reuse is the biggest lever on solver spend, this is where most of the savings come from.

The fingerprint is applied natively. Canvas, WebGL, audio, fonts, navigator, screen, timezone and locale are set inside the engine rather than patched by injected JavaScript — so there is no override script for a detector to find, and the values hold inside Web Workers and iframes where JS shims typically leak.

Automation runs over raw CDP without Runtime.enable. Clicks and keystrokes are dispatched as trusted input events and navigator.webdriver stays false. That combination is precisely what most challenge escalations are looking for, and avoiding it is worth more than any solver discount.

Extensions load per profile, so a solver extension can sit in the same session that will submit the form — no token binding mismatches to debug.

Each profile is its own OS process with its own memory and its own proxy, which makes concurrency a matter of RAM rather than careful isolation code.

If you are still deciding on tooling generally, the broader comparison lives in best antidetect browser for multiple accounts, and the sensible way to evaluate any of them is set out in what to test before you pay. Run one real target for a week before you commit to anything.

The metrics that keep this honest

Instrument these from day one; retrofitting them after a cost spike is painful.

• Challenges per 1,000 requests, broken out by domain, proxy ASN and profile cohort.
• Token acceptance rate — the target's verdict, not the vendor's.
• Cost per successfully extracted record, all-in.
• Solve latency p50 and p95, plus the queue depth those imply.
• Escalation tier distribution per domain, tracked as a trend.
• Profile mortality: how long a profile survives before its challenge rate crosses your threshold.

When a bill jumps, these six numbers tell you within minutes whether a target tightened, a proxy pool went bad, or a deploy broke your fingerprint. Without them you will guess, and you will usually guess wrong.

Law, ethics and the lines worth not crossing

None of this is legal advice, but a few things are settled enough to state plainly.

Scraping public data is not automatically unlawful. The Ninth Circuit's reasoning in hiQ Labs v. LinkedIn held that scraping publicly accessible pages does not violate the US Computer Fraud and Abuse Act, and the Supreme Court's narrowing of that statute in Van Buren pointed the same way. Terms of service are a separate matter — breaching them is generally a contract question, not a criminal one, but it is still a real risk and it varies by jurisdiction.

The practical lines that keep teams out of trouble: read robots.txt and honour crawl-delay even when it is not binding; do not scrape personal data without a lawful basis under GDPR or its equivalents; do not scrape behind an authentication wall belonging to someone else; do not use solvers against captchas protecting login, registration or password reset, because that is credential attack tooling regardless of what you call it; identify yourself in the user agent when you have no reason to hide; and keep your volume at a level that does not degrade service for the site's actual users.

Commercially, there is a version of this discipline that is just good operations. Sites that feel scraped invest in blocking. Sites that never notice you do not. Restraint is cheaper than an arms race.

Putting it together

Buy a solver — you will need one. But buy it last, after you have fixed the things that determine how often you reach for it. Harden the fingerprint. Get the proxies right. Persist sessions. Find the JSON endpoint. Then pick a vendor that supports your exact challenge type, run a three-day bake-off measuring acceptance rather than solve rate, and build the escalation ladder so the expensive path only handles the pages that genuinely need it.

Done in that order, captcha solving services for web scraping become a small, predictable line item. Done in the reverse order, they become the largest cost in your pipeline and the reason your data goes stale every time a target ships a change.

If the fingerprint and session half of that is where you are weakest, try Dual Login with one real target and one week of crawling. Watch what your challenge rate does before and after. That single number will tell you more about your architecture than any vendor comparison — including this one.

FAQ

Are captcha solving services legal to use for web scraping?

Using them is not itself illegal in most jurisdictions, and courts in the US have held that scraping publicly accessible pages does not violate the CFAA. What matters is context: bypassing a challenge that guards public product listings sits very differently from bypassing one that guards a login or registration form, which is credential attack territory. Terms of service breaches are a contract risk rather than a criminal one, but they are still a real risk. Get advice for your specific use case.

Which is cheaper, a solver or a managed unblocker API?

A solver plus your own infrastructure is roughly ten to fifty times cheaper per page once you are past a few hundred thousand pages a month — but only if you have already invested in good proxies and a credible browser fingerprint. Below that volume, or on genuinely hostile targets, the managed API usually wins because the engineering time you save is worth more than the price difference. Many teams run both, with the API as the last rung of an escalation ladder.

Why do my solved tokens keep getting rejected?

Almost always a binding mismatch. Enterprise reCAPTCHA, enterprise hCaptcha and Turnstile with client data validate the token against the IP, user agent and cookie state of the session that requested it. Pass your own proxy and user agent to the solver so it solves under the same conditions you will submit under. The other two common causes are token expiry — most are dead after about 120 seconds — and reusing a token on a retry, which never works because tokens are single-use.

Can a captcha solving service beat Cloudflare or DataDome?

Not on its own. Cloudflare Turnstile and the DataDome captcha widget can be tokened, but the managed challenge interstitials behind them are bot management, not captchas: they score your TLS handshake, HTTP/2 behaviour, JavaScript environment and IP reputation. There is no token to buy. You clear those by looking like a genuine browser on a genuine network, which is a fingerprint and proxy problem the solver cannot solve for you.

How much can better fingerprinting actually reduce my solver bill?

On the projects I have measured, moving from vanilla headless Chrome on datacentre IPs to properly fingerprinted profiles on residential IPs with session persistence cut challenge rates from roughly 20 percent to under 1 percent. That is a 20× reduction in solver spend, plus large secondary savings in latency, retry waste and worker concurrency. It is the highest-return work available in a scraping pipeline.

Do I need a different profile for every scraping session?

No, and doing so is usually counterproductive. A brand-new profile with no cookie history is a colder, more suspicious visitor than an established one. Keep a stable pool of profiles, each pinned to a consistent proxy, and reuse them across runs so their session history accumulates. Retire a profile when its individual challenge rate crosses your threshold, and replace it — do not churn the whole pool on a schedule.