Use cases · Data teams

See what iPhone users see.

Many sites serve mobile Safari a different site than desktop Chrome — different layouts, different flows, different content. If your collector isn't an iPhone, you're not collecting what iPhone users get.

The problem

The mobile web is a different web.

Point a desktop collector at a mobile-first site and you get the desktop version — or worse, a full-screen "please use our app" roadblock instead of the page. Fake the phone's user-agent string and you get the next problem: detection. Websites have gotten very good at spotting a desktop browser wearing a phone costume, because the disguise only covers the details the stealth tool remembered to fake.

Driftstack doesn't wear a costume. Every session runs the browser Apple ships on the iPhone, so what your collector sees is what an iPhone visitor would see — the mobile layout, the mobile flow, no app-steering redirects.

Why it holds up

One iPhone among millions.

Detection systems read hundreds of small signals. Driftstack sessions return the real iPhone value on every one of them — so your session lands in the iPhone bucket with millions of others.

Looks human to every website

The hidden 'device photos' sites take to spot fakes (canvas + WebGL hashes) match millions of real iPhones — not a new unique value per session like every other API

Stable across sessions

Fingerprint values match what millions of real iPhones share, session after session (population-stable); stealth Chromium mints a new one every session — 100% unique, itself a giveaway

Any country you need

Bring your own proxy or VPN, attached per profile — language and clock settings follow the exit's location

The signal-by-signal detail — what a detector measures and what each side returns — is on the comparison page.

Which plan

Collectors are code — take the API ladder.

Drive sessions from the TypeScript, Python, or Go SDK — or any HTTP client — with structured actions: navigate, interact, capture, extract. One cap on how many sessions run at the same time (think browser tabs open at once) — hours inside it aren't metered.

See API pricing →

Migrating from a Chromium vendor? The FAQ below covers what changes.

Collect responsibly: the Acceptable Use Policy draws the line in plain words — market research and price monitoring are what this page is about; scraping that gets around logins (authentication) or past a site's reasonable rate limits is not allowed.

Questions data teams ask

Before you switch — asked and answered.

Migrating from another vendor

Migrating from Browserless / Bright Data / ScrapingBee / Browserbase?

It is not just changing one URL — scripts built for those platforms can't connect to Driftstack directly (there is no CDP passthrough, the socket Chrome-automation tools plug into). Migration means reshaping your script into Driftstack's discrete REST actions (navigate / interact / wait / capture / extract) driven through the typed SDK. The fingerprint your sessions present changes too (you go from Chromium to real WebKit), so any test or production flow that depended on Chrome-specific behaviours (a specific user-agent string, Chrome-only DevTools commands, CSS bugs specific to Blink — Chrome's rendering engine) needs adjustment too. The comparison page covers feature-by-feature differences; we publish step-by-step migration guides for the common Chromium vendors — migrating from Browserless and migrating from Puppeteer. Email [email protected] if you want a hand reshaping your test suite before you cut over.

Can I run a side-by-side comparison before committing?

Yes — that's exactly what the free tier is for. Run manual sessions through Driftstack in parallel with your current vendor and compare outputs at no cost. Many customers convert to a paid tier after seeing real fingerprint match rates in their actual flows; some discover their detection-evasion problem isn't worth solving and stay on a Chromium service. Either outcome is fine — we'd rather you make the right call than the upsell.

Acceptable use

Is X allowed? (sneaker bots / scraping / ad fraud / etc.)

The full Acceptable Use Policy is at /legal/aup — read it before signing up if you're unsure. Short version: Driftstack is built for legitimate automation — QA, accessibility testing, market research, regulated-industry compliance testing, agency multi-client management, AI-agent-driven flows. We don't allow attacks on third-party systems, fraud (ad fraud, fake-account creation, payment fraud), CSAM (child sexual abuse material) or other illegal content, large-scale scraping that breaks a site's terms of service (ToS) by getting around logins or past a site's reasonable rate limits, or operating sneaker bots / ticket bots against vendors who have publicly prohibited bot purchasing. Suspected abuse triggers an account review under the Acceptable Use Policy's escalation process; persistent violations terminate the account.

What happens if Driftstack as a business goes away?

Two protections. (1) Data portability: profiles + audit logs + session metadata can be exported as CSV/JSON from the dashboard or via the API at any time, so customers can take their data with them on any timeline. (2) Self-hosted option: Enterprise + Self-hosted licensees receive source escrow — an independent third party holds a copy of our source code. If the cloud service is ever wound down, the escrow agreement releases the browser engine (the WebKit fork) and the management software (the control-plane code) so customers can keep running everything on their own hardware indefinitely. We carry no investors and no debt, so the most likely "Driftstack goes away" scenario is a planned wind-down with months of notice, not a sudden shutoff. Self-hosted on day one is the answer for customers who can't accept any cloud-vendor risk.

Everything else is on the full FAQ.

Ready when you are

Collect the web your users actually see.

Run a free manual session next to your current vendor and compare the output on your own flows — no card required.

Start free See API pricing