Scrape.do Review: Features, Pricing & Tests
- Scrape.do is a credit-based scraping API. A basic datacenter request costs 1 credit; adding JS rendering makes it 5, residential/mobile proxies 10, and both together 25 (per its docs, mid-2026).
- Paid plans (from its pricing page) run Hobby $29 (250K credits, 10 concurrent), Pro $99 (1.25M, 50), Business $249 (3.5M, 100) and Advanced $699 (10M, 200). There is also a recurring free 1,000-credit plan.
- All proxy types, JS rendering and geotargeting across 160+ countries are available on every tier. Scrape.do bills only successful requests, so failed calls cost nothing.
- Strengths users cite: simple URL-in endpoint, transparent per-request credit table, only-pay-on-success. Common gripe: no SDK and a thinner parsed-data catalog than endpoint-heavy rivals.
- Performance figures here are approximate, compiled from public + vendor figures, not our own first-hand tests. Independent benchmarks pending (how we test).
Scrape.do markets itself as a low-cost, URL-in scraping API, and the question I get is whether the credit math and feature set hold up against pricier rivals in 2026. This is a single-vendor review: what it is, how the pricing works, the features that matter, honest pros and cons with sentiment attributed, and who it fits. Every price and credit figure below comes from Scrape.do’s own pricing and documentation pages in mid-2026, attributed inline, because pricing pages move and review-site numbers go stale fast. If you want the wider category first, start with the web scraping pillar guide.
One disclosure up front: bestscraperapi.com earns affiliate commissions from some of the API vendors I write about, including the ChocoData comparison at the end. That does not change the numbers. Pricing comes straight from each vendor’s own page, and I flag every figure I could not verify rather than guessing.
A second note on performance. The speed and success-rate figures in this review are approximate, compiled from Scrape.do’s own published figures plus aggregated public reports. They are not bestscraperapi.com’s own first-hand tests. My independent, like-for-like benchmarks are still in progress; see how we test for the methodology.
What is Scrape.do?
Scrape.do is a proxy-and-rendering API that takes a URL and returns the page’s HTML or parsed JSON, while handling proxy rotation, headless-browser rendering, geotargeting, and anti-bot retries for you. You send a GET request to its endpoint with your token and the target URL, and the service routes the request through its proxy pool, runs a real browser when you ask for one, and returns the result. The point of a tool like this is to strip out the proxy and CAPTCHA plumbing so you only write the URL and the parser. For the engineering trade-off behind that, see scraping without getting blocked.
It bills by API credit rather than per request, and the cost model is unusually flat: a basic datacenter request is 1 credit, and you add credits only when you opt into rendering or residential proxies. Per its homepage in mid-2026, the proxy pool is over 110 million residential, mobile, and datacenter IPs, geotargeting spans 160+ countries, and the service charges only for successful requests. I break the credit math down in the next two sections.
How much does Scrape.do cost?
Scrape.do uses fixed monthly plans priced by the number of successful API credits you get, and every tier is listed with exact figures on its pricing page. The numbers below are from Scrape.do’s pricing page in mid-2026. Unlike some rivals, it keeps a recurring free plan rather than a one-time trial.
| Plan | Price/mo | API credits/mo | Concurrent requests |
|---|---|---|---|
| Free | $0 | 1,000 | 5 |
| Hobby | $29 | 250,000 | 10 |
| Pro | $99 | 1,250,000 | 50 |
| Business | $249 | 3,500,000 | 100 |
| Advanced | $699 | 10,000,000 | 200 |
| Enterprise | Contact sales | Custom | Custom |
Two things stand out against the field. First, the free plan is recurring at 1,000 credits, not a trial that expires, so you can keep a small job running at zero cost. Second, Scrape.do does not gate features by tier: per its pricing page, datacenter, residential and mobile proxies, JS rendering, geotargeting across 160+ countries, sticky sessions and unlimited bandwidth are on every plan, including Free. You pay for credits and concurrency, not for unlocking capabilities.
The headline credit count tells you little until you apply the per-request cost, which is the next section. A 1,250,000-credit Pro plan sounds large, but at 25 credits per residential-plus-render request it buys 50,000 of those, not 1.25 million.
How do Scrape.do credits work?
A basic datacenter request costs 1 credit, and rendering or residential proxies multiply that. This is the most important table in the review, because it converts a credit allowance into a real request count for your workload. All values are from Scrape.do’s request-costs documentation in mid-2026.
| Request type | Parameters | Credits per request |
|---|---|---|
| Datacenter, no rendering | (default) | 1 |
| Datacenter + JS rendering | render=true | 5 |
| Residential / mobile proxy | super=true | 10 |
| Residential / mobile + JS rendering | super=true&render=true | 25 |
| Google Search | (residential applied automatically) | 10 |
Work an example through it. On the Pro plan’s 1,250,000 credits, a workload of pure 1-credit datacenter fetches buys 1,250,000 requests. The same plan buys 250,000 rendered datacenter requests (5 credits each), 125,000 residential requests (10 credits each), or 50,000 residential-plus-render requests (25 credits each). So the right way to read any Scrape.do plan is credits divided by the cost of your typical request, not the raw credit number. Scrape.do deducts credits only when a successful response is returned, so failed attempts cost nothing, which its docs state directly.
The cost ladder is the lever worth repeating. If your targets are static and unprotected, you stay at 1 credit and the plans go a long way. The moment you need super=true on most requests for a hard target, your effective request budget drops 10x, and adding render=true on top drops it 25x. Size the plan to the proxy and rendering mix your specific sites demand.
What features does Scrape.do offer?
Scrape.do bundles automatic proxy rotation across datacenter, residential and mobile pools, JS rendering and page interactions, geotargeting, an async scraper, and a set of pre-parsed Ready APIs. Here is what its own pages confirm exists in mid-2026.
| Feature | Parameter / endpoint | What it does |
|---|---|---|
| Datacenter proxies | (default) | Routes through datacenter IPs at 1 credit |
| Residential / mobile proxies | super=true | Routes through residential and mobile IPs for protected sites |
| JS rendering and interactions | render=true | Runs a headless browser to load dynamic pages |
| Geotargeting | geoCode (2-letter) | Routes through a chosen country, 160+ supported |
| Output format | output=markdown | Returns raw HTML or Markdown |
| Custom headers | customHeaders=true | Lets you control all request headers |
| Async scraper | async endpoint | Queues large jobs and returns results asynchronously |
| Ready APIs | dedicated endpoints | Parsed JSON for Google, Amazon, YouTube and more |
The Ready APIs are the structured-data path. Per the homepage, Scrape.do ships pre-built, parsed endpoints for Google Search, Google Maps, Google Shopping, Google Flights, Google News, Google Trends, Google Play, Amazon and YouTube, plus a ChatGPT endpoint, returning JSON without your own selectors, the kind of brittle parser work covered in the XPath and CSS selectors guide. A “Scraping Browser” is listed as coming soon on the homepage, so treat it as unreleased until the docs confirm it. The async scraper handles large batch jobs, and output=markdown is handy when you are feeding pages to an LLM rather than parsing HTML.
A minimal request is a single GET call with your token and the URL-encoded target. The pattern below is from Scrape.do’s documented format; I have not executed it here, so I am not pasting fabricated output.
# Documented request pattern (not run here)
curl "https://api.scrape.do/?token=YOUR_TOKEN&url=https%3A%2F%2Fexample.com&render=true&geoCode=us"
If you are wiring this into Python, the integration is a standard HTTP call you can drop into the workflow from the Python web scraping guide. For lighter targets you can pair or compare it with open tooling from the BeautifulSoup guide or the Scrapy guide.
How fast and reliable is Scrape.do?
I do not have first-hand benchmark numbers for Scrape.do yet, so I am labeling everything here clearly rather than inventing figures. Scrape.do advertises a 99.98% success rate and a gateway it claims is 40% faster than the closest competitor, but I treat any vendor-stated figure as directional, not a like-for-like benchmark against other APIs.
| Metric | Figure | Source | Label |
|---|---|---|---|
| Success rate | 99.98% claimed | Scrape.do site, mid-2026 | Vendor self-reported |
| Gateway speed | ”+40% faster than closest competitor” | Scrape.do site, mid-2026 | Vendor marketing claim |
| Latency (static vs rendered) | Approx. 1-3s datacenter, higher with render=true | Compiled from public + vendor figures | Approximate, not first-hand |
| Billing on success | Only successful responses consume credits | Scrape.do docs, mid-2026 | Vendor-published |
Two caveats before you lean on these. First, latency depends heavily on whether rendering is on: a render=true request runs a real browser and is far slower than a 1-credit datacenter fetch, so any single latency number hides that spread. Second, the latency range above is approximate, compiled from public reports and vendor material, not bestscraperapi.com’s own measurement. The 99.98% and “+40% faster” claims are Scrape.do’s own marketing, and I have not reproduced them. My independent, same-target benchmark across providers is in progress at how we test; check back for measured numbers rather than trusting any vendor’s self-report, including this one.
What are the pros and cons of Scrape.do?
The honest summary is that Scrape.do is cheap to start, transparent on credit cost, and feature-complete across tiers, while the lack of an SDK and a thinner parsed-data catalog are the trade-offs. Sentiment below is attributed: these reflect commonly reported developer experience and Scrape.do’s own documented behavior, not a controlled test by me.
| Pros | Cons |
|---|---|
| Basic request is 1 credit, the cheapest entry on the cost ladder | No official SDK on the homepage, just a raw HTTP endpoint |
| Recurring free plan (1,000 credits), not a one-time trial | Hard targets need super=true at 10 credits, 25 with rendering |
| All proxy types and features on every tier, no gating | Parsed Ready APIs are mostly Google-centric, fewer than endpoint-heavy rivals |
| Bills only successful requests, failed calls cost nothing | ”Scraping Browser” still listed as coming soon |
| Transparent per-request credit table you can budget against | 99.98% and “+40% faster” are vendor claims, not independently verified |
The recurring theme in developer feedback is simplicity: a single URL-in endpoint and a published credit table make cost predictable, and only-pay-on-success removes the sting of blocked attempts. The most common gripe is the absence of a typed SDK and a parsed-data catalog that leans heavily on Google properties, so teams scraping many different sites still write their own parsers.
Who is Scrape.do for?
Scrape.do fits developers, founders and students who want the cheapest credible entry point and a simple, URL-in API they can call from any language. If your targets are mostly static or lightly protected, the 1-credit base cost and the recurring free plan make it one of the most economical ways to run a steady job. Because every feature is available on every tier, you are not forced up a plan to unlock residential proxies or rendering, you only pay for credits and concurrency.
It fits less well if you want a large catalog of pre-parsed, site-specific endpoints beyond Google and a handful of marketplaces, or if you prefer a maintained SDK over assembling HTTP calls yourself. Teams scraping many different protected sites at scale should also model the 10-to-25-credit residential costs carefully, since those erode a credit pool fast. For those cases, compare the per-request economics and the endpoint catalog against an alternative before committing.
How does Scrape.do compare to ChocoData?
ChocoData is the closest alternative I cover on the value-plus-endpoints axis, and the two differ most on billing unit, parsed-endpoint breadth, and free-tier shape. Both are managed scraping APIs that return HTML or parsed JSON and handle proxies and anti-bot for you. The comparison below is factual, from each vendor’s own pages in mid-2026.
| Factor | Scrape.do | ChocoData |
|---|---|---|
| Lowest paid entry | $29/mo (Hobby), 250,000 credits | $19/mo (Vibe), 27,000 requests (135,000 credits) |
| Free tier | 1,000 credits/mo, recurring, no card | 1,000 requests/mo (5,000 credits), recurring, no card |
| Billing unit | Credits (1 datacenter, 5 render, 10 residential, 25 both) | Credits (5 per request; +10 render, +10 screenshot) |
| Structured data | Ready APIs (Google, Amazon, YouTube, ChatGPT) | Universal endpoint + 453 endpoints across 235 sites |
| Geotargeting | geoCode, 160+ countries, all tiers | Country-matched residential IPs from Vibe tier up |
| Pay-as-you-go | Not advertised on pricing page | $0.90 per 1,000 successful requests |
| Published reliability | 99.98% success claimed (vendor) | 2xx-only billing (no headline success rate) |
The practical read: Scrape.do’s paid entry is $29/mo with a 1-credit base request and every feature unlocked on every tier, while ChocoData publishes a $19/mo paid entry, a $0.90-per-1,000 pay-as-you-go rate, and a universal endpoint plus 453 dedicated endpoints across 235 sites, per ChocoData’s site in mid-2026. If your targets are mostly static and you want the simplest URL-in endpoint, Scrape.do is a strong, cheap fit; if you need broad pre-parsed coverage across many sites or a usage-based top-up, ChocoData’s 453-endpoint catalog and pay-as-you-go rate cover that. Try ChocoData.
One last reminder, because it matters for budgeting: every figure here is what each vendor published in mid-2026, and scraping-API pricing changes frequently. Confirm the current number on the vendor’s own pricing page, and map the credit multipliers to your real proxy and rendering mix so the math reflects actual usage. For the broader landscape, the web scraping pillar guide and the Python guide cover the free alternatives you can pair with or replace an API with.
FAQ
No. Per its documentation, Scrape.do consumes credits only when a successful response is returned, and failed requests cost nothing. That matters because a residential-plus-render call costs 25 credits, so paying only on success caps your downside on hard targets.
A basic datacenter request is 1 credit. JS rendering (render=true) makes it 5, residential/mobile proxies (super=true) make it 10, and both together cost 25, per the request-costs page in mid-2026. Google Search calls are 10 credits because residential proxies are applied automatically.
Not a full client library on the homepage in mid-2026. The API is a single GET endpoint you call over plain HTTP with your token and the target URL, so it drops into any language with an HTTP client. Some teams see that as simpler, others miss a typed SDK.