Cross-Browser and Device Emulation
A single Playwright test file can run unmodified against Chromium, Firefox, and WebKit — Apple's Safari rendering engine — because Playwright ships patched builds of all three and exposes the exact same API surface regardless of which one is driving the browser. This is configured through the projects array in playwright.config.ts, where each project specifies a name and a use block (typically use: { ...devices['Desktop Chrome'] } or similar), and running npx playwright test executes every test against every configured project by default, giving genuine multi-engine coverage without maintaining separate test suites per browser.
Cricket analogy: It's like a bowler's action being legal and effective whether they're bowling with a Kookaburra ball in Australia, a Dukes ball in England, or an SG ball in India, without needing to relearn their action for each manufacturer.
Configuring Browser Projects
In practice, most teams configure three or more projects: one each for Chromium, Firefox, and WebKit using use: { ...devices['Desktop Chrome'] }, use: { ...devices['Desktop Firefox'] }, and use: { ...devices['Desktop Safari'] } respectively, and you run a subset with npx playwright test --project=webkit when you only need to debug one engine. Because each project is independently configurable, teams commonly scope expensive or flaky-prone suites (like full visual regression tests) to run only on Chromium in CI to save time, while still running the core functional suite across all three engines to catch genuine cross-browser bugs like WebKit's stricter clipboard permission model or Firefox's different default font rendering.
Cricket analogy: It's like a franchise fielding separate specialist net-bowling squads for pace, spin, and left-arm variations, running every batter through all three during full training camp, but only against the pace squad during a quick tune-up before a match.
Emulating Mobile Devices
Playwright bundles a devices dictionary with dozens of preset device profiles like devices['iPhone 13'] and devices['Pixel 5'], each bundling a realistic viewport size, device scale factor, user agent string, and touch/mobile flags (isMobile: true, hasTouch: true) so a test project can emulate a phone without owning physical hardware or a device farm. Spreading a preset into a project's use block (use: { ...devices['iPhone 13'] }) is usually sufficient, but you can override individual fields — for example forcing viewport to a custom size while keeping the iPhone's user agent and touch behavior — for testing responsive breakpoints that don't map exactly to a real shipped device.
Cricket analogy: It's like a franchise using a bowling machine calibrated to replicate Jasprit Bumrah's exact release point and pace for practice, instead of needing the real bowler present at every single net session.
Geolocation, Locale, and Permissions
Beyond viewport and user agent, Playwright's use block can set geolocation (a lat/long coordinate plus accuracy), locale (affecting Accept-Language headers and Intl formatting), timezoneId, colorScheme ('light', 'dark', or 'no-preference'), and permissions (an array like ['geolocation', 'notifications'] that pre-grants browser permission prompts so tests don't hang waiting for a dialog a headless browser can't click). These options combine to let a single test suite verify, for example, that a store-locator feature correctly finds nearby shops when geolocation is set to Tokyo coordinates with locale: 'ja-JP', without needing an actual device physically located in Japan.
Cricket analogy: It's like a broadcaster setting the on-screen graphics package to Hindi commentary with IST timestamps for the Indian feed of a match, while simultaneously running an English, GMT-timestamped feed for UK viewers, from the same live footage.
// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
projects: [
{ name: 'chromium', use: { ...devices['Desktop Chrome'] } },
{ name: 'firefox', use: { ...devices['Desktop Firefox'] } },
{ name: 'webkit', use: { ...devices['Desktop Safari'] } },
{
name: 'mobile-safari-jp',
use: {
...devices['iPhone 13'],
locale: 'ja-JP',
geolocation: { latitude: 35.6762, longitude: 139.6503 },
permissions: ['geolocation'],
colorScheme: 'dark',
},
},
],
});
// Run only one project: npx playwright test --project=webkitThe devices dictionary (imported from @playwright/test) is generated from real device specs and kept up to date across Playwright releases — spreading devices['iPhone 13'] into use gives you a realistic viewport, DPR, user agent, and touch configuration in one line instead of hand-assembling each field.
WebKit in Playwright approximates desktop and mobile Safari closely but isn't a bit-for-bit identical build to the Safari shipped on an actual iPhone — for regulated or highly Safari-sensitive flows (like Apple Pay or in-app purchase UI), supplement Playwright's WebKit coverage with periodic testing on real Apple hardware or a device farm.
- One Playwright test suite runs unmodified across Chromium, Firefox, and WebKit via the projects array in playwright.config.ts.
- Each project has its own use block, commonly seeded from devices['Desktop Chrome'/'Desktop Firefox'/'Desktop Safari'] presets.
- --project=<name> runs a single browser project for focused debugging instead of the full multi-engine matrix.
- The devices dictionary provides realistic mobile presets (viewport, DPR, user agent, touch flags) like devices['iPhone 13'].
- geolocation, locale, timezoneId, colorScheme, and permissions can all be configured per project or per test.
- Pre-granting permissions (e.g., ['geolocation']) avoids tests hanging on a browser permission dialog headless mode can't interact with.
- WebKit approximates Safari closely but isn't identical to real device Safari, so Safari-critical flows deserve occasional real-device verification.
Practice what you learned
1. How does Playwright run the same test suite across Chromium, Firefox, and WebKit?
2. What does spreading devices['iPhone 13'] into a project's use block configure?
3. Why would you pre-grant permissions like ['geolocation'] in a project's use block?
4. How do you run tests against only the WebKit project without running Chromium or Firefox?
5. Why is real-device testing still recommended for Safari-critical flows despite Playwright's WebKit support?
Was this page helpful?
You May Also Like
Fixtures and Test Hooks
How Playwright's fixture system and lifecycle hooks provide reusable, isolated setup and teardown for tests.
Component Testing with Playwright
How Playwright's component testing mode mounts individual React, Vue, or Svelte components in a real browser for fast, isolated tests.
Visual Comparisons and Screenshots
How Playwright captures, compares, and maintains screenshot baselines to catch visual regressions that functional assertions miss.