Playwright vs Selenium Interview Questions (2026)

Playwright is the modern, faster, TypeScript-first framework with native auto-wait, parallel-by-default execution, and trace viewer. Selenium is the mature, cross-language W3C-standard tool with the biggest install base and enterprise footprint. In 2026: pick Playwright for greenfield, Selenium for existing Java/Grid shops.

Playwright — often 2–5x on the same suite. Reasons: single WebSocket connection per browser (vs HTTP-per-command for WebDriver), workers run tests in parallel by default, and auto-wait eliminates dead sleeps.

Selenium: Java, Python, C#, Ruby, JavaScript, Kotlin. Playwright: TypeScript/JavaScript, Python, Java, .NET. Selenium wins on Ruby; Playwright wins on TypeScript ergonomics.

Playwright — every action waits for visible + stable + enabled + receiving-events before firing. Selenium requires explicit waits (WebDriverWait + ExpectedConditions).

Playwright — first-class BrowserContext and page.context().pages(). Selenium supports it via getWindowHandles(), but the API is more verbose and less isolated.

The single biggest architectural gap between the two frameworks is how the test process talks to the browser. Selenium sends one HTTP request per command over the JSON Wire / W3C WebDriver protocol. Playwright opens a single, persistent WebSocket connection using a CDP-derived protocol and streams every command and event through it.

Real-world takeaway: on a 500-test regression, the transport alone accounts for a meaningful chunk of runtime. WebSocket also unlocks features Selenium can only bolt on later (network interception, tracing, dialog handlers) because the browser can push events without the client asking.

The JSON Wire Protocol (now the W3C WebDriver spec) was designed in 2011 to be a REST-like RPC on top of HTTP. Every action — findElement, click, getAttribute — is a separate HTTP call to http://localhost:PORT/session/<id>/<action>. WebSocket, born in RFC 6455, is a persistent full-duplex tunnel: after one handshake the client and server can push frames both ways.

Why this matters in an interview answer:

• Latency compounds. A UI test can fire 50–200 protocol calls per scenario. Multiply by suite size × CI runs per day and JSON Wire's per-call overhead becomes the pipeline's biggest hidden cost.
• Event push kills polling. Playwright can subscribe to Network.responseReceived or Page.dialog and act the instant the browser fires them. Selenium has to loop with WebDriverWait, which is where most flakiness starts.
• Backpressure & ordering. A single WS with monotonically increasing id preserves command order per browser context. HTTP concurrency has to be serialised in the driver, which is why Selenium WebElement references can go stale.
• Firewalls. WS runs over the same 80/443 as HTTP and passes through most corporate proxies — the myth that WebSocket is blocked in the enterprise is largely gone in 2026.

If an interviewer probes deeper, mention that Selenium 4 can use BiDi (also WebSocket-based) for a subset of features — proof that the industry direction is one persistent socket, not many HTTP calls. Deep dive: Playwright vs Selenium (2026 comparison) and the pillar comparison blog.

Playwright: npm i -D @playwright/test && npx playwright install — one command, bundles browsers. Selenium: add dependencies, drivers auto-download via Selenium Manager (4.6+), then wire in TestNG/JUnit.

No — Playwright is parallel-by-default via workers on a single machine. For horizontal scaling: shard with --shard=N/M across CI runners. Selenium needs Grid (or a cloud like BrowserStack) to fan out.

// Playwright
await page.goto('/login');
await page.getByLabel('Email').fill('qa@x.com');
await page.getByLabel('Password').fill('secret');
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page).toHaveURL('/dashboard');

// Selenium (Java + JUnit)
driver.get("/login");
driver.findElement(By.id("email")).sendKeys("qa@x.com");
driver.findElement(By.id("password")).sendKeys("secret");
driver.findElement(By.id("submit")).click();
new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.urlContains("/dashboard"));

Playwright: auto-waits for domcontentloaded/networkidle. Selenium: explicit wait on a stable element or URL change. Never rely on pageLoadTimeout alone for SPAs.

Playwright's getByRole, getByLabel, getByTestId are accessibility-first and self-healing. Selenium's By.* is lower-level: id, css, xpath, plus Selenium 4 relative locators. Playwright's locators are lazy and re-evaluate; Selenium's WebElement can go stale.

Playwright's expect(locator).toHaveText(...) auto-retries until the condition passes or times out. Selenium requires you to combine WebDriverWait + JUnit/TestNG assertion. Auto-retrying assertions are Playwright's single biggest flake-killer.

// Playwright
const frame = page.frameLocator('#pay');
await frame.getByRole('button', { name: 'Pay' }).click();

// Selenium
driver.switchTo().frame("pay");
driver.findElement(By.id("pay-btn")).click();
driver.switchTo().defaultContent();

// Playwright — auto-retrying
await expect(page.getByTestId('spinner')).toBeHidden();

// Selenium
new WebDriverWait(driver, Duration.ofSeconds(10))
  .until(ExpectedConditions.invisibilityOfElementLocated(By.id("spinner")));

Playwright, materially — auto-wait, auto-retry assertions, isolated BrowserContext per test, and the Trace Viewer for post-mortem. Selenium flakes are usually solvable with disciplined explicit waits and POM, but the ceiling is lower.

// Playwright — parallel by default; tune workers
// playwright.config.ts
export default { workers: 4 };

<!-- TestNG suite -->
<suite name="R" parallel="methods" thread-count="8">

Selenium also needs a ThreadLocal<WebDriver> to keep sessions isolated.

// Playwright — first-class
await page.route('**/api/users', r => r.fulfill({ json: [{ id: 1 }] }));

Selenium has to use Selenium 4 CDP (DevTools) or a proxy like BrowserMob — clunkier and Chromium-only.

Playwright: trace: 'on-first-retry' + open the Trace Viewer (DOM snapshots, network, console, actions timeline). Selenium: screenshots on failure via TestNG listener + Extent/Allure reports. Playwright's DX is meaningfully better here.

Both need add-ons. Playwright: built-in HTML reporter + Trace Viewer. Selenium: Extent Reports, Allure, or ReportPortal via TestNG listener. Trace Viewer wins for step-by-step debugging.

Neither — both are for web browsers. For native mobile you still need Appium (WebDriver-based). Playwright supports mobile emulation in Chromium/WebKit, but that's not real device testing.

Same strategy in both: bypass in test environments (test-mode CAPTCHA keys, direct-grant OAuth flows, seeded sessions). Neither tool magically solves CAPTCHAs.

• Existing Java/TestNG + Grid suite with hundreds of tests
• Need Ruby / C# / Kotlin support
• Enterprise / BFSI / gov shops with WebDriver-based tooling
• Real Safari on macOS via SafariDriver

• Greenfield project with TypeScript/JavaScript/Python
• Modern SPA (React/Vue/Angular) with heavy async
• Team wants fast feedback loops and low flakiness
• Cross-browser (Chromium + Firefox + WebKit) without infra

Deep dive: Playwright vs Selenium (2026 comparison).

1. Freeze new Selenium test additions
2. Port page objects one-by-one, keeping data models
3. Replace explicit waits with Playwright's auto-wait + expect
4. Add trace: 'on-first-retry' from day one
5. Run both suites in CI until parity, then delete Selenium

Depends on the market. India / US enterprise: Selenium still edges by JD count. US startups / EU product companies: Playwright is climbing fast and pays a premium. Ideal candidate knows both — see our Selenium 300 Q&A and Playwright Q&A.