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 an orderly 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