Should I test my website against all browsers and versions?

Do not test your website against all browsers and versions, because old Safari versions alone need old iPhones or a paid device cloud. Run the main flows in Chromium, Firefox and WebKit, and alert on finished flows per browser.

Do I still need to test in both Chrome and Safari?

Yes, Chrome and Safari need separate test runs, because Chrome left WebKit for its own Blink engine in April 2013, as the Chromium blog announced. Run the main flows in Chromium and WebKit. Chrome on iPhone uses WebKit, because App Store guideline 2.5.6 requires WebKit unless Apple grants an alternative engine, which it offers only in the EU and Japan.

Is Playwright's WebKit the same as Safari?

Playwright's WebKit is not Safari: the Playwright browsers page says it is built from the WebKit main branch with Playwright's own patches, and Playwright cannot drive branded Safari. Checks of Safari's own interface, such as its iPhone toolbar, need Safari on a device or in the iOS Simulator.

Which browsers should I test my website in?

Test your website in the engines behind the browsers in your analytics: Blink for Chrome and Edge, Gecko for Firefox, and WebKit for Safari and for Chrome on iPhone.

Should I test in every browser?

Verdict

Test it differently

Watch each browser in production instead of testing every browser and version: record errors and finished main flows per browser, alert when one browser falls below its usual rate, and roll releases out in stages.

Why

Blast radiususers
Change frequencyregularly
Detectabilityeventually
Reversibilitywith-effort
Test costprohibitive

Do not test every browser and version; watch each browser in production instead. My typical case is a customer-facing web app that the team builds in Chrome. Blast radius is users, because a break in one browser stops everyone who uses it, and Change frequency is regularly, because the app changes about once a month. Detectability is eventually, because nobody on the team opens Safari before merging, and users who meet a dead button leave without naming their browser. Reversibility is with-effort: a script that fails in one engine can save forms with missing fields, and those records need a repair. Test cost is prohibitive, because Safari runs only on Apple hardware and old iOS versions do not install on a current iPhone, so rule R4 gives Test it differently.

When the decision changes
When	Decision	Why
The main flows already have a Playwright suite, and your analytics show visitors in Chrome, Safari and Firefox	Test: run the suite in Chromium, Firefox and WebKit projects on every pull request	Test cost falls to moderate: three engines cover the browsers built on them, and one config change reuses the existing tests
Buyers pay at checkout in Safari on an iPhone	Test mandatory: run the checkout test in Safari on an iPhone or in the iOS Simulator before each release	Blast radius rises to money and Reversibility to costly, because a lost sale does not come back; Test cost falls to heavy, because one flow runs in one browser
A customer contract lists the browsers and versions your product must support	Test mandatory: run the main flows in each listed browser before every release and keep the results	Blast radius rises to safety-or-legal, because a break breaks the contract, and Test cost falls to heavy, because the list is short and fixed
An internal tool that staff open in the browsers the company installs, changed a few times a year	Do not test other browsers: name the supported browsers and fix what colleagues report	Blast radius falls to internal, Change frequency to rarely and Detectability to same-day, because colleagues report a break that day

What breaks if you don't test

A full-screen panel sized with 100vh hides its button under Safari's toolbar on an iPhone, or a form calls a browser API that Safari implements differently. Users of that browser give up, and support hears about it weeks later, if at all.

What you lose if you over-test

A matrix of every browser and version multiplies each suite run by the number of combinations, and each engine adds its own timing failures. Old Safari versions need old iPhones or a paid device cloud. A red run in an old Firefox gets rerun until it passes.

What to do instead

Record front-end errors and finished main flows per browser family and major version, and alert when one browser falls below its own usual rate.
Roll releases out in stages, and keep the previous build ready to redeploy.
Pick targets from your analytics with Browserslist: > 1% in my stats lists the browsers your visitors use.
Test one browser per engine: Chrome and Edge build on Blink, Firefox on Gecko, Safari on WebKit. If the main flows have an end-to-end suite, run it in Playwright's Chromium, Firefox and WebKit projects. Playwright's WebKit is not branded Safari, so the reviewer opens a changed layout in Safari on an iPhone before release.

Procedure and references

When the answer changes

Money moves in the flow that can break, as in checkout.
A contract names the browsers you must support.
Your main flows already have an end-to-end suite.

Real incident + Code example

The button under Safari's toolbar

On a scheduling product I worked on, the last signup step on phones was a panel with height: 100vh and the Create account button at its bottom. vh measures the page with the browser toolbar hidden, as MDN explains, so in Safari on iPhone the toolbar covered the button, and the panel did not scroll. Chrome's device emulation and Playwright's iPhone profile draw no toolbar, so both showed the button. Nobody wrote to support. Sixteen days later the weekly funnel showed that iPhone visitors finished signup about a third less often. The fix was height: 100dvh, plus this query as an hourly alert:

-- Signup finish rate per browser: last 7 days against the 28 days before.
-- A returned row fires the alert: one browser dropped 20% below its own baseline.
WITH rates AS (
  SELECT browser,  -- family and major version, such as 'Mobile Safari 17'
         created_at > now() - interval '7 days' AS recent,
         count(*) FILTER (WHERE step = 'finished')::numeric
           / nullif(count(*) FILTER (WHERE step = 'started'), 0) AS finish_rate
  FROM signup_events
  WHERE created_at > now() - interval '35 days'
  GROUP BY browser, recent
)
SELECT r.browser, r.finish_rate AS last_7_days, b.finish_rate AS baseline
FROM rates r
JOIN rates b ON b.browser = r.browser AND NOT b.recent
WHERE r.recent
  AND r.finish_rate < 0.8 * b.finish_rate;

Sources

Should I test CSS?No
Should I test every screen size?Test it differently
Is automated UI testing worth it?Yes
Is visual regression testing worth it?No
Are end-to-end tests worth it?Yes

FAQ

Should I test my website against all browsers and versions?: Do not test your website against all browsers and versions, because old Safari versions alone need old iPhones or a paid device cloud. Run the main flows in Chromium, Firefox and WebKit, and alert on finished flows per browser.
Do I still need to test in both Chrome and Safari?: Yes, Chrome and Safari need separate test runs, because Chrome left WebKit for its own Blink engine in April 2013, as the Chromium blog announced. Run the main flows in Chromium and WebKit. Chrome on iPhone uses WebKit, because App Store guideline 2.5.6 requires WebKit unless Apple grants an alternative engine, which it offers only in the EU and Japan.
Is Playwright's WebKit the same as Safari?: Playwright's WebKit is not Safari: the Playwright browsers page says it is built from the WebKit main branch with Playwright's own patches, and Playwright cannot drive branded Safari. Checks of Safari's own interface, such as its iPhone toolbar, need Safari on a device or in the iOS Simulator.
Which browsers should I test my website in?: Test your website in the engines behind the browsers in your analytics: Blink for Chrome and Edge, Gecko for Firefox, and WebKit for Safari and for Chrome on iPhone.