Cross-browser testing, and why browsers differ

A web app must work in every browser your users use — and browsers are not identical. A page that is perfect in Chrome (where the developer built it) can be broken in Safari, misaligned in Firefox, or fail on an older Edge. Cross-browser testing is checking the app across the browsers that matter, and it is a core web-QA concern with no mobile equivalent. This lesson is why browsers differ, what breaks, and how to test across them without checking every browser by hand forever.

Why browsers differ

A browser is a large, complex program that interprets your HTML, CSS and JavaScript — and different browsers are built by different teams (Google's Chrome/Chromium, Apple's Safari/WebKit, Mozilla's Firefox/Gecko) on different engines. They mostly agree (web standards exist), but they differ in real ways:

• Rendering engines interpret CSS slightly differently — spacing, flexbox/grid edge cases, fonts, form-control styling. A layout can be pixel-perfect in one and subtly off in another.
• Feature support varies — a newer CSS or JavaScript feature may be supported in Chrome but not yet (or differently) in Safari; a modern API may be missing on an older browser version. The app may silently break where the feature is absent.
• Safari is the common surprise — because it uses WebKit and updates on Apple's schedule, Safari (especially on iPhones/iPads) frequently behaves differently from Chrome, and it is the browser developers test least (they are usually on Chrome). "Works in Chrome, broken in Safari" is a classic bug.
• Older versions lag — a user on an old browser version misses features the developer's up-to-date browser has.

So "it works" in the developer's Chrome does not mean it works for a user on Safari or Firefox or an older browser — exactly the "works on my machine" trap, in browser form.

What breaks across browsers

The bugs cross-browser testing finds cluster in a few areas:

• Layout and rendering — elements misaligned, overlapping, clipped, or wrongly sized; a flexbox/grid layout that reflows differently; fonts rendering at different sizes.
• Form controls — date pickers, dropdowns, file inputs and checkboxes are styled and behave differently per browser (Safari's date input is notably different).
• JavaScript behaviour — a feature that works in one engine throws an error in another, breaking interactivity; console errors that appear only in one browser.
• CSS features — a newer property not supported, so the layout falls back badly.
• Functionality that silently fails — a feature relying on an unsupported API just does nothing on that browser, with no obvious error to the user.

The insidious ones are the silent failures — the app does not crash, it just renders wrong or does nothing on one browser, and the developer (on Chrome) never sees it. Only testing in that browser reveals it.

Test the browsers that matter — from data

You cannot test every browser and version (there are many), and you should not try. As with mobile devices, use your users' actual data:

• Get analytics on which browsers and versions your users use, and test those, weighted by how common they are.
• Cover the engines — at minimum, one of each major engine: a Chromium browser (Chrome/Edge), Safari (WebKit), and Firefox (Gecko) — because most differences are engine-level, so covering the three engines covers most of the risk.
• Include the awkward ones your users have — Safari (especially if you have iPhone users), and any older versions your analytics show a meaningful share on.
• Prioritise by usage and by risk — test the critical flows on all the major browsers; test minor features on fewer.

A defensible cross-browser strategy is "the top browsers/versions our users are on, covering all three major engines, with critical flows checked on each" — not "every browser ever", and not just "Chrome, where I built it".

How to test across browsers efficiently

Checking every flow in every browser by hand is slow and dull — so you use a mix:

• Manual spot-checks in real browsers for the important flows and any layout-sensitive screens — install Chrome, Firefox and Safari (Safari needs a Mac or an iOS device) and go through the critical paths.
• Cross-browser cloud services (BrowserStack, Sauce Labs, LambdaTest) give you every browser/version/OS combination without installing them — the practical way to check the long tail (an old Safari, a specific Edge version) you cannot hold locally.
• Automation across browsers — this is where Playwright shines (the web-automation module): it runs the same automated tests across Chromium, Firefox and WebKit engines, so your regression suite catches cross-browser breakage automatically on every run. Automating the cross-browser check is far better than re-doing it by hand each release.
• caniuse.com — to check whether a specific CSS/JS feature is supported in the browsers you care about, when you suspect a feature-support bug.

The efficient approach: automate the cross-browser regression (Playwright across engines) so it is checked every run, spot-check layout-sensitive and new screens manually in real browsers (especially Safari), and use a cloud service for the versions you cannot install. That covers the real risk without checking every browser by hand forever.

Check your work

Why browsers differ. Different engines (Chromium, WebKit/Safari, Gecko/Firefox) interpret CSS/JS slightly differently and support features differently; older versions lag. "Works in the developer's Chrome" ≠ works everywhere — the browser form of "works on my machine". Safari is the common surprise.

What breaks. Layout/rendering (misalignment, reflow, fonts), form controls (date pickers, dropdowns — Safari notably), JavaScript behaviour (errors in one engine), unsupported CSS/JS features, and silent functional failures (works nowhere-visibly on one browser). The silent ones are the trap.

Which browsers. From user analytics, weighted by usage; cover all three major engines at minimum; include Safari (esp. with iPhone users) and older versions with real share; critical flows on all majors, minor features on fewer — not "every browser", not "just Chrome".

How to test efficiently. Manual spot-checks in real browsers (Safari especially) for critical/ layout-sensitive screens; cloud services (BrowserStack etc.) for the versions you cannot install; automate cross-browser regression with Playwright across engines; caniuse.com for feature support.

Practice

1. Open a web app in Chrome, Firefox and (if you can) Safari; go through a key flow and note any layout, form-control or behaviour difference.
2. Find a form with a date input or dropdown and compare how it looks and behaves across two browsers.
3. Given (hypothetical) user analytics, choose the set of browsers/versions to test and justify covering all three engines.
4. Use caniuse.com to check whether a CSS/JS feature is supported in the browsers your users have.
5. Reproduce a "works in Chrome, broken in Safari" style bug (or reason about how you would find one), and note why the developer never saw it.
6. Describe how you would use Playwright to make cross-browser checking part of every test run rather than a manual chore.

Official documentation

• MDN — Cross-browser testing — Why browsers differ and how to test across them.
• Can I use… — Browser support tables for CSS/JS features.
• BrowserStack — Live cross-browser testing — Every browser/version without installing them.

Next: responsive layouts, screen sizes and rendering.