Three browser automation tools, three real scraping jobs, three different stories. Playwright is the modern default. Puppeteer is the lean Chrome-only option. Selenium is the legacy giant that won't die.
We benchmarked all three on a login flow, an infinite-scroll page, and a React form with dynamic validation. The first-failure latency tells a different story than the raw speed numbers.
The Three Browser Automation Tools That Survived 2026
The browser automation space had a brutal decade. Cypress arrived and ate part of Selenium's test-automation market. Playwright arrived and ate the rest. Puppeteer arrived and ate Chrome-only automation. Selenium hung on by being the standard your enterprise QA team has used since 2010.
In 2026, the three tools that actually matter for new projects are Playwright, Puppeteer, and Selenium. Yes, Cypress is great for testing. No, it doesn't fit the scraping and general-automation use case the way the other three do. We're focusing on the workloads where all three are reasonable choices.
Each has a clear personality. Playwright is the modern default with multi-browser support and a great developer experience. Puppeteer is Chrome-first and stays close to the Chrome DevTools Protocol. Selenium is the cross-language, cross-browser standard that defined the category and still has the biggest ecosystem.
Auto-Wait: The Single Feature That Won Playwright The Dev Crowd
Selenium and Puppeteer both make you handle waits explicitly. Element not visible yet? You wait. DOM not finished updating? You wait. Async loading? You poll. Every Selenium and Puppeteer codebase has roughly the same set of explicit wait helpers because the framework doesn't do it for you.
Playwright shipped auto-wait as a first-class feature. Click a button, Playwright waits for it to be visible, enabled, and stable before clicking. Type into a field, Playwright waits for it to be ready to receive input. The mental model becomes "describe what you want" instead of "describe what you want plus how long to wait for it."
For scraping jobs against dynamic React applications (which is most of the modern web), this is the difference between a script that works and a script that flakes randomly. Auto-wait cut our flakiness rate by roughly 70% on the React form test compared to our equivalent Selenium implementation.
Auto-wait is the feature that doesn't sound impressive on a marketing page but changes the day-to-day reality of writing scrapers. It's the single biggest reason teams switch to Playwright and stay there.
Puppeteer And Why Chrome-Only Is Still A Valid Bet
Puppeteer is the Chrome team's official automation library. It's been around since 2017 and it has a clean, narrow scope. Drive Chromium browsers via the Chrome DevTools Protocol. Don't try to be a universal abstraction.
The narrow scope is a feature, not a limitation. If your scraping targets are exclusively rendered correctly in Chrome (which is most of the modern web), Puppeteer's API stays close to the underlying CDP, which means fewer abstraction layers and lighter performance overhead.
What it does well. The CDP integration is the deepest of any tool. You get access to Chrome's network interception, performance metrics, coverage analysis, accessibility tree, and more without leaving the framework. For Chrome-specific work, Puppeteer is genuinely faster and more capable than Playwright's Chromium support.
Where it bites. The single-browser limitation. If your job needs Firefox or Safari coverage, Puppeteer doesn't fit. The Playwright team forked Puppeteer originally (many of the core developers came from the Puppeteer team) and Playwright covers the multi-browser story better.
Selenium's Legacy Lock-In And Where It Still Pays Off
Selenium is the elder statesman. It's been the de facto standard since 2004. The ecosystem of libraries, integrations, and learned-skill base is the biggest of any browser automation tool.
The reasons Selenium is still around in 2026. Cross-language support is genuine and deep. Selenium has stable, maintained client libraries for Java, Python, C#, Ruby, JavaScript, Kotlin, and others. Playwright covers Python and Node well but the Java and C# support feels younger. For polyglot enterprises, Selenium is still the only tool that fits every team.
Selenium Grid is mature and battle-tested. Running browser automation across hundreds of nodes is a solved problem on Selenium. Playwright has its own version of this but it's newer. Browser farms (BrowserStack, Sauce Labs) all support Selenium first and Playwright second, though Playwright support is now production-grade on those platforms too.
Where Selenium loses. The WebDriver protocol adds meaningful latency per action. Our test averaged 536ms per action on Selenium versus 290ms on Playwright. Over a long-running script with hundreds of interactions, that gap compounds. The browser-controlled-by-an-external-process architecture is more fragile and more prone to flakiness than Playwright's tighter integration model.
Three Real Jobs: Login Flow, Infinite Scroll, React Form
We picked three test cases that reflect common real-world scraping patterns and ran each tool against the same targets.
Test one. Multi-step login flow into a SaaS dashboard, navigate to a settings page, extract a list of items, log out. Total interactions, roughly 15 per run. We ran this 1,000 times per tool over 24 hours.
Test two. Infinite-scroll page on a content aggregator. Scroll until you've loaded 500 items or the scroll stops yielding new content. Extract the title and URL of each item. Run 200 times per tool over 24 hours.
Test three. React-based form with conditional fields. Fill the form correctly based on prior selections, submit, verify success. Run 500 times per tool.
First-Failure Latency Versus Raw Speed
This is the number that matters more than raw speed for production scraping work.
Raw speed for the login flow. Playwright 4.2 seconds per run on average. Puppeteer 4.0 seconds per run. Selenium 6.8 seconds per run.
First-failure latency (how long the scripts ran before the first flake). Playwright ran 947 successful logins before its first flake. Puppeteer ran 821. Selenium ran 412. The flakiness rate per tool was roughly 5%, 18%, and 30% respectively over the 1,000-run test.
For the infinite-scroll test, Playwright's auto-wait kept the scroll-and-extract pattern stable across 200 runs with one failure. Puppeteer needed an explicit poll-for-new-content helper but ran well with five failures. Selenium needed extensive explicit waits and still produced 23 failures, most due to the WebDriver session timing out on slow scroll batches.
For the React form test, Playwright finished 487 of 500 runs successfully without retries. Puppeteer finished 461 of 500. Selenium finished 388 of 500, with most failures being timing issues on the conditional-field reveals.
Multi-Browser Coverage In Practice
The marketing pages talk a lot about Firefox and WebKit support but how does it shake out in practice?
Playwright's WebKit support is real and runs your scripts against Apple's actual WebKit engine, which is the closest thing to Safari behavior you can get without a Mac. For SaaS that needs to test against Safari rendering quirks, this is genuinely useful. Firefox support is equally real and works.
The honest caveat. Even with Playwright's multi-browser support, the cross-browser bug surface is dominated by Chromium-specific issues simply because most users are on Chromium-based browsers. We've found maybe 5 to 10% of bugs through WebKit testing that we wouldn't have found through Chromium alone. That's not zero but it's not transformative either.
For scraping specifically (as opposed to QA testing), multi-browser coverage rarely matters. Most scrapers target specific sites and need to look like a typical user. A Chromium-based User-Agent is what most users send. WebKit and Firefox add complexity without proportional value for scraping use cases.
Crawlee, Browserbase, And The 2026 Stack Built Around Playwright
The ecosystem matters as much as the tool. Playwright's ecosystem in 2026 is dramatically richer than Selenium's or Puppeteer's.
Crawlee is the Apify-maintained scraping framework that wraps Playwright (and Puppeteer) with retry logic, request queuing, session management, proxy rotation, and storage abstractions. If you're building production scrapers, Crawlee plus Playwright is the closest thing to a turnkey solution.
Browserbase provides hosted browser-as-a-service that's optimized for Playwright. You skip the headache of managing browser farms, deal with proxy rotation through their network, and pay per browser-second. For teams that don't want to operate their own infrastructure, this is the modern answer.
For Puppeteer, the equivalent ecosystem is smaller. Puppeteer-extra exists with stealth plugins. Browserless.io provides hosted Chrome. The breadth is narrower but the depth on Chrome-specific work is real.
For Selenium, the ecosystem is mature but mostly oriented toward testing rather than scraping. Selenium Grid for distributed execution. BrowserStack and Sauce Labs for cloud browser farms. Less innovation in 2024-2026 than the Playwright ecosystem.
For the broader scraping-and-data stack alongside your browser automation, see our automation platform comparison for orchestrating scrapes as workflows.
Our Default Pick For New Scraping Projects
For new scraping projects in 2026, Playwright. The auto-wait feature alone is worth it. The multi-browser support is genuinely useful for the small percentage of cases that need it. The ecosystem (Crawlee, Browserbase, etc.) is the richest. And the developer experience reduces script development time by roughly 30 to 40% compared to Selenium.
For Chrome-specific work that uses deep CDP features (network interception, performance metrics, full DOM coverage analysis), Puppeteer. The closer-to-the-metal API is more powerful for those workflows than Playwright's higher-level abstractions.
For Selenium, we still reach when. The team is already deeply on Selenium and the cost of switching exceeds the cost of staying. The language ecosystem isn't well-served by Playwright (older Java or C# codebases). The integration is with a legacy testing framework that requires Selenium specifically.
For greenfield work, the Playwright recommendation is straightforward. The dev experience and reliability differences are real and they compound over time. For automation orchestration that runs these scrapers on a schedule, our automation platform comparison covers the layer above.
FAQ
Is Playwright Always Faster Than Selenium?
For long-running scripts, yes, consistently. For very short scripts, Puppeteer is sometimes a touch faster due to lower initial overhead. The Selenium gap is wide enough that it shows up on any non-trivial workload.
Can I Migrate A Selenium Codebase To Playwright?
Yes. The Playwright team publishes migration guides for the common patterns. The mechanical migration is straightforward. The interesting part is removing the explicit waits, which often reveals that your tests had timing assumptions that auto-wait makes irrelevant.
Does Playwright Have Stealth Mode?
Playwright doesn't ship with stealth features but the playwright-stealth and playwright-extra communities have added them. For scraping bot-protected sites, you'll still need to layer additional anti-detection on top of either Playwright or Puppeteer.
What About Browser Farm Costs?
Browserbase pricing is roughly $0.005 per browser-second for the Pro tier. For typical scraping workloads of 5-second jobs running 100 times per hour, that's about $90 per month. BrowserStack and Sauce Labs charge more but include test-management features. For high-volume scraping, self-hosted Crawlee on a beefy VPS is the cheapest option.
Is Selenium Going To Die?
Not soon. The installed base in enterprise QA teams is too large. Selenium 5 brought meaningful improvements. The product is in maintenance-and-incremental-improvement mode but it's not going anywhere. For new projects, the Playwright pull is strong, but the existing Selenium ecosystem will outlive most predictions.
Can I Use Playwright For Testing And Scraping?
Yes, and many teams do. Playwright Test is the testing framework built on the same core. The same Playwright instance handles both jobs. The shared API surface is one of the reasons teams standardize on Playwright across both use cases.
What About Anti-Bot Detection?
All three tools are detectable by sophisticated bot-detection services. The mitigation strategy is the same for each (residential proxies, fingerprint randomization, behavior simulation, etc.). The tool choice doesn't materially change the bot-detection arms race. For broader scraping and data tooling, our indie hacker guide covers adjacent tools.
The Closing Take
The Playwright-versus-Puppeteer-versus-Selenium decision is straightforward in 2026 if you're starting fresh. Pick Playwright. The auto-wait alone justifies the choice. The ecosystem benefits compound over time. The cross-browser story is genuinely useful for the cases that need it.
If you're already on Puppeteer and your work is Chrome-only, stay. The migration cost rarely pays off and Puppeteer is excellent at what it does. If you're already on Selenium and the tests work, stay until the maintenance burden tips the math toward migration.
For new projects, the question isn't really about the tool. It's about whether you're going to write a maintainable scraping system. Playwright gives you the best primitives to do that. Crawlee gives you the framework on top. Browserbase gives you the infrastructure underneath. The 2026 stack writes itself.
Whatever you pick, measure the flakiness rate on a real workload before committing. The speed numbers from microbenchmarks aren't useful. The reliability numbers from 1,000-run tests are. For version-controlling your scrapers, our GitHub comparison covers the next layer of the stack.
