Stealth mode: when to flip it on, and what it costs
Stealth mode runs a hardened browser that reads as a real visitor. Flip it on for sites that block the default fetch, and know the surcharge before you do.
Leave stealth mode on for every request and you can double a scraping bill without getting a single extra page. It feels like the safe default: a real browser that gets through the hard targets, pointed at all of them. It also means paying the top tier's surcharge on the static pages that would have answered a plain fetch at base cost.
So treat stealth as a cost decision, not a quality setting. You flip it on for the specific sites that have earned it, and leave it off everywhere else.
What stealth mode actually does
The default fetch starts cheap. A request goes out as a fast HTTP call carrying a
real browser's fingerprint, and only if a site answers with a 403, a 429, or a
timeout does the retry climb to a browser. Stealth is a different path. With
stealth: true, the request runs through a hardened, anti-detection browser from
the first attempt, so it presents as an ordinary visitor rather than working its
way up a ladder the site is built to reject.
The part worth internalizing: this tier is opt-in. The engine escalates a struggling request up to a headless browser on its own, but it does not reach for the stealth tier automatically. That one stays off until you ask for it, which is why knowing when to ask is worth a few minutes. The full escalation story is in beating bot detection without overpaying.
When to flip it on
Three signals justify the surcharge.
- A persistent block. The default fetch comes back with a 403 or a challenge page even after its own retry. Not a one-off, but the same refusal every time. The site is rejecting anything that doesn't read as a real browser session.
- A target you already know is hostile. When you've established that a site blocks the cheap path, there's no value in spending the cheap attempts first. Starting on stealth skips the round-trips that were going to fail anyway.
- A page that renders client side. Some pages return a 200 with an empty shell and fill in the content with JavaScript afterward. The default path won't auto-render that, because a 200 isn't a failure it retries. Stealth runs the page in a real browser, so the scripts execute and the data comes back.
| Signal | Verdict |
|---|---|
| A persistent 403 or challenge after the default retry | Yes, flip it on |
| A 200 empty shell on a client-rendered page | Yes, it runs the JavaScript |
| A single 403 you haven't retried | Not yet, let the default path try |
| A 429, too many requests | No, slow down instead |
| A static page a plain fetch already returns | No, you'd pay the surcharge for nothing |
The two "no" rows are where credits leak. A lone 403 is often cleared by the default retry, so forcing stealth there pays for a browser you didn't need. And a 429 is a pacing problem, covered in how to scrape a site that keeps blocking you: a stealth browser hitting the same limit at the same rate gets the same 429 at a higher cost.
What it costs
Stealth adds a fixed surcharge per endpoint, on top of the base cost:
/v1/scrape: 1 credit by default, 3 with stealth./v1/smartscraper: 5 credits, or 10 with stealth./v1/crawl: 1 credit per page, or 2 per page with stealth./v1/search: the base scales with results requested; stealth adds 1 when it scrapes the result pages.
The surcharge applies only when stealth runs, and credits are charged on success only, so a stealth fetch that fails costs nothing. Turning it on to test a hostile target is a bounded expense.
The case against defaulting it on is arithmetic. Suppose you're scraping 1,000 pages and, on your target mix, 1 in 10 actually needs stealth. Force it on every call and you pay 1,000 × 3 = 3,000 credits. Leave it off and let the engine escalate only where forced: 900 pages clear on the default path at 1 credit, 100 need stealth at 3, for 900 + 300 = 1,200 credits. The ratio of pages that need stealth is yours to measure, but the shape holds for any mix where most pages are reachable cheaply.
# Leave stealth off first. Flip it on only for the targets that earn it.
curl https://api.webscrape.ai/v1/scrape \
-H "X-API-Key: wsg_live_your_key_here" \
-d '{ "website_url": "https://tough-target.example/page", "stealth": true }'
Where stealth stops helping
Stealth is the heaviest fetch tier, and it still isn't a guarantee. A site can refuse the request outright, gate the content behind a login the fetch can't satisfy, or serve a challenge a scraper shouldn't be solving. None of those are fixed by trying harder, and one of them is the site telling you no. Respect the target's terms of service and robots.txt before you decide getting through is worth it. For the pages where rendering or a login is the real blocker rather than detection, when you need a headless browser draws the line between a rendering problem and an access one.
There's a quieter failure too. A block and a client-rendered shell can look identical from the outside, since both hand you a page without your data, so you won't always know which lever you need before you pull it.
Default off, on by exception
Make stealth a per-target choice: off by default, on for the specific sites that keep refusing the cheap path. Then read the bill to confirm you only paid the surcharge where a page forced it. Point a key at a target you're unsure about with stealth off, and let the response tell you whether you need to turn it on, with the free credits a new account starts with and nothing lost on a fetch that fails.
Frequently asked questions
When should I use stealth mode for scraping?
Turn on stealth when the default fetch keeps coming back blocked on a target, when you already know a site is hostile and want to skip the cheaper attempts, or when a page renders client side and returns an empty shell. For most pages the default path is enough, so leave it off.
How much does stealth mode cost?
Stealth adds a per-endpoint surcharge on top of the base cost. On /v1/scrape it's 1 credit by default and 3 with stealth; on /v1/smartscraper it's 5 or 10; on /v1/crawl it's 1 or 2 per page. The surcharge applies only when stealth runs, and only on success.
Does stealth mode make scraping slower?
Usually, yes. Stealth runs a full browser from the first attempt instead of starting with a fast HTTP request, so it does more work per fetch. That's the trade for getting through sites that block lighter requests. On pages that don't need it, the extra work buys nothing.
Should I turn on stealth for a 429 error?
No. A 429 means you're requesting pages faster than the site allows, and a stealth browser hitting it at the same rate gets the same 429 at a higher cost. Slow down instead: add a delay between requests and lower your concurrency before trying again.
Is stealth mode billed if the fetch fails?
No. Credits are charged on success only, so a stealth fetch that never returns the page costs nothing. You pay the surcharge only when stealth actually gets you the content, which makes turning it on to test a hostile target a bounded cost.
Will stealth mode get me past every block?
No. Stealth widens what's reachable, but a site can still refuse the request, gate content behind a login, or present a challenge a scraper shouldn't be solving. Treat it as the heaviest fetch tier, not a guarantee, and respect the target's terms of service and robots.txt.