Chromium vs WebKit Screenshots in Playwright: What Changes?

A screenshot difference between Chromium and WebKit does not, by itself, mean your application regressed. Browser rendering, fonts, operating systems, browser versions, and capture settings can all affect pixels. Use a stable capture environment and maintain a separate visual baseline for each Playwright browser project.

Playwright recommends using the same environment that generated a visual baseline. It also notes that rendering can vary with the host OS, browser version, settings, hardware, power source, and headless mode. Playwright visual comparisons document these sources of variation.

1. What Chromium and WebKit mean in Playwright

Playwright’s Chromium project uses Playwright’s own Chromium build by default. Its WebKit project uses a WebKit build from WebKit main-branch sources. Playwright WebKit is not the branded Safari browser, and a WebKit screenshot should not be treated as an exact image of every Safari release or Apple device. Platform capabilities can vary by operating system. See Playwright’s browser documentation.

The browser project names describe the engine builds Playwright runs. They do not promise pixel identity with an installed Chrome or Safari version.

2. What can change in the screenshot?

There is no universal list of pixels or CSS properties that always differ between these engines. The outcome depends on the page and capture environment; this follows from Playwright’s documented browser and platform variation, rather than from a fixed Chromium-versus-WebKit delta.

When investigating a diff, check these axes:

• Fonts: confirm the same font files are installed or loaded and that font loading finishes before capture. Different available fonts or rendering can change glyph shapes and line wrapping.
• Layout: inspect changed line breaks, element sizes, and positions. These are possible manifestations of rendering differences, not guaranteed engine defects.
• Platform: record the operating system and platform-specific browser capabilities.
• Browser build and Playwright version: keep versions stable between baseline creation and comparison.
• Screenshot scale: CSS-pixel and device-pixel output can have different dimensions.
• Capture mode and conditions: keep headless mode, settings, hardware, and power conditions stable where possible.

3. Configure Chromium and WebKit projects

Install Playwright and its browser binaries through your project’s normal setup, then define separate projects. This runnable example uses Playwright Test and TypeScript:

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'], browserName: 'chromium' },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'], browserName: 'webkit' },
    },
  ],
});

Create a screenshot assertion in a test:

import { test, expect } from '@playwright/test';

test('home page visual baseline', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveScreenshot('home.png');
});

Run all configured projects with npx playwright test, or select one with npx playwright test --project=webkit or npx playwright test --project=chromium. On the first run, Playwright can generate reference snapshots; review and commit those files according to your team’s baseline workflow.

Keep independent baselines for Chromium and WebKit. Playwright’s snapshot naming includes browser and platform by default; in multi-project configurations, project names can be used in snapshot paths. See snapshot path documentation. A baseline should represent the browser project and environment it is intended to check, rather than an expectation that two different engines render identical pixels.

4. Stabilize capture settings

Choose screenshot scale deliberately

Page screenshots can use scale: 'css' for one image pixel per CSS pixel or scale: 'device' for device-pixel output. Device-scale screenshots can be larger on high-DPI configurations. Keep scale consistent when creating and comparing baselines.

await page.screenshot({ path: 'page.png', fullPage: true, scale: 'css' });

For toHaveScreenshot(), the documented default scale is CSS. The page screenshot API describes screenshot options.

Wait for a stable image

toHaveScreenshot() waits for two consecutive screenshots to match before comparing the last capture with the reference. This helps avoid capturing while a page is still changing.

Use animation controls, masks, or a stylesheet for genuinely volatile content. For example:

await expect(page).toHaveScreenshot('home.png', {
  animations: 'disabled',
  mask: [page.locator('[data-testid="live-clock"]')],
});

You can also apply a screenshot stylesheet to hide known dynamic regions. Use masks and hidden elements sparingly: they can hide the UI behavior the test is meant to protect. See the screenshot assertion options.

Set tolerances as a review policy

Playwright supports a perceived color threshold and limits for the number or ratio of different pixels. Its documented default perceived color threshold is 0.2 on its YIQ comparison scale. That is a tool default, not a measurement of typical Chromium-versus-WebKit differences.

Start with a threshold suited to your team’s need to detect changes. Inspect the diff before relaxing it. A larger tolerance can suppress noise, but it can also allow meaningful visual changes through. The assertion documentation explains threshold, maxDiffPixels, and maxDiffPixelRatio.

5. Diagnose a difference systematically

1. Confirm the baseline belongs to the same project. Compare Chromium output with its Chromium baseline and WebKit output with its WebKit baseline.
2. Check whether the environment changed. Verify OS, Playwright version, browser binaries, headless mode, settings, and available fonts.
3. Check image dimensions and scale. Confirm that CSS-pixel versus device-pixel capture and device scale factor did not change.
4. Make the page deterministic. Wait for the intended content and fonts; disable animations or mask a volatile region only when that is appropriate.
5. Inspect the diff at the changed region. Look for text wrapping, layout movement, or changed content, then decide whether the difference is an application issue, an expected engine variation, or capture noise.
6. Change one variable at a time. Keep other conditions fixed while testing a suspected cause. This is practical diagnostic guidance, not a Playwright guarantee.
7. Update a baseline only after review. A changed reference should represent an accepted UI change in that browser project.

If your goal is broad compatibility, decide whether you need engine coverage, OS/device coverage, or both. Add projects that reflect supported users rather than multiplying every possible configuration by default. Playwright supports browser and device projects; platform capabilities can differ.

6. Common problems and fixes

Symptom	Likely cause	What to do
Chromium passes but WebKit fails against the same expected image	One baseline is being shared across different browser projects	Maintain separate project-specific snapshots and compare each project to its own reference.
Many unrelated snapshots change on a new machine	OS, browser build, fonts, settings, hardware, or headless mode changed	Regenerate and compare baselines in the intended stable environment; review the resulting diffs before accepting them.
Image dimensions do not match	Screenshot scale or device scale factor differs	Use the same scale and viewport/device configuration for baseline and actual captures.
Text wrapping changes intermittently	Fonts or page content may not have settled before capture	Ensure the intended fonts and data are ready, then let the screenshot assertion stabilize the image.
Diffs appear around transitions or live content	Animation or volatile content changes between captures	Disable animations where suitable, or mask the specific volatile region without concealing behavior under test.
A larger threshold makes failures disappear	The tolerance may be hiding genuine changes as well as harmless pixel noise	Inspect diffs and tune the threshold or pixel limit only as a deliberate review policy.
WebKit output does not exactly match Safari on a device	Playwright WebKit is not the branded Safari app, and platform capabilities vary	Treat it as WebKit engine coverage; use a browser and platform matrix that matches the compatibility question you need to answer.

7. Performance, reliability, and cost

Running multiple browser projects means running the test workload in each selected project. Choose a matrix that answers a real compatibility question, and keep the environment consistent so failures remain interpretable. This article does not claim a particular runtime overhead or benchmark.

Stable versions, fixed capture settings, and project-specific references make visual checks easier to reproduce. A visual baseline is evidence about a particular page in a particular capture configuration; it is not proof that every browser and platform renders identically.

Playwright’s native screenshot assertions let teams manage reference images and diffs in their repository. For managed visual review or expanded browser coverage, Percy documents Playwright integration and BrowserStack Automate options; Chromatic documents visual snapshots in Playwright E2E workflows; Applitools documents Playwright support and cross-browser visual testing. Evaluate them against your workflow. The research for this article does not establish comparative prices, performance, or product quality for these services.

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. It can return a PNG, JPEG, WebP, or PDF from one GET request. It is an alternative when you need screenshot capture without managing a browser installation for that request; a screenshot API is not a replacement for browser-specific visual regression baselines.

For a fair engine comparison, capture the same stable page with your browser projects and keep their baselines separate. ScreenshotNeo is useful for getting clean page captures: it accepts cookie or consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture. Each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers say which verdict applied and whether the request was billed.

One-call example using cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation. Equivalent Python and Node.js examples:

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo also offers an MCP server for AI agents, with take_screenshot, get_page_info, and capture_pdf tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Every feature is on every plan. Sign up for 1,000 free screenshots a month, with no card.

9. Frequently asked questions

Should Chromium and WebKit use separate visual baselines?

Yes. Each project represents a different browser configuration, so compare it with a baseline generated for that project.

Does a WebKit screenshot prove how Safari looks?

No. Playwright WebKit is based on WebKit sources, but it is not the branded Safari browser. Treat it as WebKit engine coverage, not a guarantee of pixel identity with every Safari release and platform.

Is a 0.2 color threshold the expected Chromium-to-WebKit difference?

No. It is Playwright’s documented default perceived-color threshold for screenshot assertions, not a measured cross-browser difference.

Can I make Chromium and WebKit screenshots identical?

Do not assume they will be identical. You can stabilize the environment and capture settings, but rendering and fonts can still vary between browsers and platforms.