Learn the fastest way to make a full page screenshot in Chrome, plus better options for long pages, mobile captures, scheduled screenshots, and screenshot automation.
Learn what Puppeteer is, how it controls browsers, and how to use it for automation, testing, scraping, screenshots, PDFs, and performance workflows.
GuideStop running a browser, a parser, and a Markdown converter for every URL you process. One AllScreenshots request returns the screenshot, the main content, and the meta tags you need — billed as a single screenshot.
Developers, marketers, and founders use Allscreenshots to automate website captures. No credit card required to get started.
Cross-browser testing is not about proving that every pixel is identical in every browser. Browsers do not render exactly the same way, and your users are not all running the same engine, viewport, operating system, or device settings.
The goal is more practical: prove that critical user journeys still work in the browsers your audience depends on, catch browser-specific layout and JavaScript issues before release, and keep the test suite fast enough that developers trust it.
Playwright is a strong fit for that job because it can run the same tests against Chromium, Firefox, and WebKit from one test runner. It can also emulate mobile devices, run branded Chromium browsers such as Google Chrome and Microsoft Edge, capture traces, and split work across CI jobs.
This guide focuses on how to build a Playwright cross-browser setup that gives useful coverage without turning every pull request into a slow browser matrix.
Start by deciding what risk you are trying to reduce. A good cross-browser suite usually answers these questions:
It should not try to duplicate every unit test in every browser. That creates more runtime than signal. Use Playwright for browser behavior and real user flows. Keep business logic, pure functions, and edge-case permutations in cheaper test layers.
Make the cross-browser suite intentionally small at first. A fast suite that runs on every pull request is more valuable than a complete suite that developers only run before major releases.
Playwright's core browser projects map to three engines:
| Project | Engine | Useful coverage |
|---|---|---|
| Chromium | Blink/V8 | Chrome, Edge, many desktop users, most Android browser behavior |
| Firefox | Gecko/SpiderMonkey | Firefox-specific layout, event, storage, and media behavior |
| WebKit | WebKit/JavaScriptCore | Safari-like rendering, iOS-style issues, WebKit-specific layout behavior |
Playwright can also run against branded Google Chrome and Microsoft Edge through browser channels, and it can emulate selected desktop, tablet, and mobile device profiles.
There are two important caveats:
Those caveats do not make the coverage weak. They just mean you should treat Playwright as a practical automation layer, not as a perfect substitute for every physical device and browser combination.
Most teams should start with one Playwright config that defines browser projects. The project names become the handles you use locally and in CI.
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
testDir: './tests/e2e',
timeout: 30_000,
expect: {
timeout: 5_000
},
use: {
baseURL: process.env.PLAYWRIGHT_BASE_URL || 'http://localhost:3000',
trace: 'on-first-retry',
screenshot: 'only-on-failure',
video: 'retain-on-failure'
},
projects: [
{
name: 'chromium',
use: { ...devices['Desktop Chrome'] }
},
{
name: 'firefox',
use: { ...devices['Desktop Firefox'] }
},
{
name: 'webkit',
use: { ...devices['Desktop Safari'] }
},
{
name: 'mobile-chrome',
use: { ...devices['Pixel 5'] }
},
{
name: 'mobile-safari',
use: { ...devices['iPhone 12'] }
}
]
});Run everything:
npx playwright testRun one browser project:
npx playwright test --project=webkitRun one test file in one browser:
npx playwright test tests/e2e/checkout.spec.ts --project=firefoxThat last command is the one developers use most often when debugging a browser-specific failure.
Running every test in every browser sounds thorough, but it usually becomes expensive quickly. A better matrix separates critical coverage from broad coverage.
| Suite | Browser coverage | When to run |
|---|---|---|
| Smoke flows | Chromium, Firefox, WebKit, mobile Chrome, mobile Safari | Every pull request |
| Full functional suite | Chromium | Every pull request |
| High-risk browser suite | Firefox and WebKit | Pull requests touching CSS, browser APIs, auth, checkout, uploads, downloads, or navigation |
| Full matrix | All configured projects | Nightly, before releases, or on demand |
You can express this by splitting tests into folders:
tests/
e2e/
smoke/
login.spec.ts
checkout.spec.ts
dashboard.spec.ts
full/
billing-settings.spec.ts
team-management.spec.ts
exports.spec.tsThen run the smoke folder across every project and the full suite in Chromium:
npx playwright test tests/e2e/smoke
npx playwright test tests/e2e/full --project=chromiumThis gives you browser breadth where it matters most and keeps routine CI practical.
Cross-browser tests are less forgiving than single-browser tests. Small assumptions that pass in Chromium can fail in Firefox or WebKit.
Role, label, placeholder, and text locators are usually more resilient than CSS selectors.
import { test, expect } from '@playwright/test';
test('visitor can request a product demo', async ({ page }) => {
await page.goto('/pricing');
await page.getByRole('link', { name: /book a demo/i }).click();
await expect(page.getByRole('heading', { name: /schedule a demo/i })).toBeVisible();
});CSS selectors often depend on implementation details that vary after refactors:
// Fragile
await page.locator('.pricing-card:nth-child(2) .button.primary').click();
// Better
await page.getByRole('link', { name: /start pro trial/i }).click();Hard waits hide real readiness problems and behave differently across engines and CI machines.
// Avoid
await page.waitForTimeout(2000);
// Prefer a user-visible signal
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
await expect(page.getByText('Project created')).toBeVisible();Hover behavior differs across desktop and touch-style projects. If a menu is essential on mobile, the product should expose a touch-friendly path. Your test should reflect the real control for that viewport.
test('navigation opens product links', async ({ page }) => {
await page.goto('/');
const viewport = page.viewportSize();
const isMobileViewport = viewport ? viewport.width < 768 : false;
if (isMobileViewport) {
await page.getByRole('button', { name: /open navigation/i }).click();
} else {
await page.getByRole('button', { name: /products/i }).hover();
}
await expect(page.getByRole('link', { name: /integrations/i })).toBeVisible();
});Fonts, antialiasing, form controls, scrollbars, focus rings, and media codecs can differ between engines and operating systems. Functional tests should assert user outcomes, not exact CSS internals.
For visual checks, compare screenshots inside a stable environment and keep browser-specific baselines separate. A WebKit screenshot should not usually be compared against a Chromium baseline.
Some browser projects need different settings. For example, you may want a stricter reduced-motion environment for visual tests, or a branded Chrome channel for codec-heavy workflows.
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
projects: [
{
name: 'chromium',
use: { ...devices['Desktop Chrome'] }
},
{
name: 'chrome-stable',
use: {
...devices['Desktop Chrome'],
channel: 'chrome'
}
},
{
name: 'webkit-reduced-motion',
use: {
...devices['Desktop Safari'],
reducedMotion: 'reduce'
}
}
]
});Use branded Chrome or Edge when you specifically need the installed browser channel, media codecs, enterprise browser policy behavior, or parity with a customer support environment. For normal regression testing, the bundled browser projects are simpler and more reproducible.
For CI, install the Playwright browsers and operating system dependencies before running the suite.
name: Playwright cross-browser tests
on:
pull_request:
push:
branches: [main]
jobs:
smoke:
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v6
with:
node-version: lts/*
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test tests/e2e/smoke
- uses: actions/upload-artifact@v5
if: failure()
with:
name: playwright-report
path: playwright-report/
retention-days: 30
chromium-full:
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v6
with:
node-version: lts/*
- run: npm ci
- run: npx playwright install --with-deps chromium
- run: npx playwright test tests/e2e/full --project=chromium
- uses: actions/upload-artifact@v5
if: failure()
with:
name: playwright-report-chromium-full
path: playwright-report/
retention-days: 30If the suite grows, split it with sharding:
npx playwright test --shard=1/4
npx playwright test --shard=2/4
npx playwright test --shard=3/4
npx playwright test --shard=4/4For a large matrix, run each project as a separate job. That makes failures easier to read and lets CI parallelize the slowest work.
strategy:
fail-fast: false
matrix:
project: [chromium, firefox, webkit, mobile-chrome, mobile-safari]
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v6
with:
node-version: lts/*
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test tests/e2e/smoke --project=${{ matrix.project }}Do not hide browser-specific failures by rerunning the whole matrix until it passes. Use retries to collect a cleaner signal, but treat repeat failures in one browser as product or test bugs that need investigation.
When a test fails in only one browser, resist the urge to guess. Capture the browser's view of the page.
Start with the failing project:
npx playwright test tests/e2e/checkout.spec.ts --project=webkit --headedThen use traces:
npx playwright show-trace trace.zipA trace helps you inspect:
Useful failure patterns include:
| Symptom | Common cause |
|---|---|
| Works in Chromium, fails in WebKit | Safari/WebKit layout difference, unsupported API, focus behavior, date input, sticky positioning |
| Works locally, fails in CI | Missing OS dependency, font difference, slower hardware, hidden race condition |
| Works on desktop, fails on mobile project | Different navigation pattern, covered button, viewport-specific layout, touch target issue |
| Fails only in Firefox | CSS support difference, event handling difference, storage or download behavior |
When a test exposes a real browser bug in your app, keep the regression test. Narrow it to the behavior that failed so the next person understands why it exists.
Playwright can capture screenshots during tests:
await page.screenshot({
path: 'artifacts/pricing-webkit.png',
fullPage: true
});Screenshots are useful for debugging and for visual checks around high-value pages. But screenshot-heavy workflows become expensive when every browser, route, state, and viewport runs inside the same end-to-end suite.
A practical split is:
For broad visual coverage, pair Playwright with Allscreenshots screenshot automation:
const response = await fetch('https://api.allscreenshots.com/v1/screenshot', {
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.SCREENSHOT_API_KEY}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({
url: 'https://example.com/pricing',
fullPage: true,
viewport: { width: 1440, height: 900 },
format: 'png'
})
});
if (!response.ok) {
throw new Error(`Screenshot failed: ${response.status}`);
}That keeps the Playwright suite focused on behavior while screenshot automation handles repeatable capture, visual regression testing, and scheduled page monitoring.
If you are adding cross-browser testing to an existing app, do it in stages:
This sequence gives you useful coverage early and avoids making browser testing feel like a tax on every change.
Playwright makes cross-browser testing approachable, but the value comes from the matrix you choose. Run your most important flows across Chromium, Firefox, WebKit, and mobile projects. Keep the full suite concentrated where it gives the best signal. Use traces to debug browser-only failures, and use screenshot automation when the job is broad visual coverage rather than interaction testing.
Done well, cross-browser testing becomes a focused release safety net instead of an expensive checklist.