Cross-browser testing

Browsers share web standards but not every detail of how they apply them. A layout that is tidy in Chrome on a laptop can overlap in Safari on an iPhone, a date picker can behave differently in Firefox, and a newer CSS feature can be missing in an older browser that some visitors still run. Cross-browser testing finds those differences before your visitors do.

How we choose the browsers

We start from your analytics where you have them. The browsers, versions and operating systems that real visitors use decide the test matrix, so effort goes where your audience is. If there is no analytics data yet, for example on a brand-new site, we use a default set and say so in the report.

The default set covers the current release of each major engine on the platforms where it is used:

• Chrome on Windows, macOS and Android.
• Edge on Windows.
• Firefox on Windows or macOS.
• Safari on macOS and on a real iPhone, because Safari on iOS has its own handling of scrolling, fixed headers and form controls that desktop testing does not show.

Where your data shows a meaningful number of visits from an older version, we add it. We also check whether the features your site depends on are Baseline features, a status maintained by the web platform community that tells you when a feature works across Chrome, Edge, Firefox and Safari. Our guide to cross-browser testing in 2026 explains how Baseline helps decide what to test.

What we check in each browser

• Layout and rendering. Headers, menus, grids, cards, images and fonts at the widths each browser is used at.
• Interaction. Menus, accordions, sliders, tabs, modal windows and anything else that responds to clicks, taps or keys.
• Forms. Inputs, date and time fields, file uploads, autofill behaviour and validation messages, which can differ between browsers.
• Media. Video and audio playback, embedded maps and third-party widgets.
• Console errors. JavaScript errors that appear in one browser and not another can explain a feature that silently fails.
• Print styles where you expect visitors to print, such as menus, tickets or invoices.

Real browsers, real devices

We test in installed browsers on real hardware wherever possible, and use emulation only to widen coverage. Emulators and responsive design modes are useful for layout at different widths, but they do not reproduce touch behaviour, on-screen keyboards, or the way iOS handles fixed headers when the address bar collapses. When a finding comes from emulation rather than a real device, the report says so.

How findings are reported

A browser difference is only a defect if it affects the visitor. A font rendering a fraction differently in Firefox is not worth reporting; a button label wrapping onto two lines and pushing the button off screen in Safari is. Every cross-browser finding in our reports answers three questions:

1. What is different? A side-by-side screenshot from the affected browser and a browser where it works.
2. Who is affected? The browser, version and platform, and where your analytics allows, how much of your traffic uses that combination.
3. What does it break? Whether the difference is cosmetic, makes a task harder, or stops it entirely, which sets the severity.

That third question is the one that decides what gets fixed before launch.

Browser updates after launch

Browsers update themselves on their own release schedules, and a site that worked at launch can meet a change months later. An update may make no visible difference, but a change to how a feature behaves, or the removal of something long deprecated, can affect older code. If your site depends on a feature with limited availability, or uses third-party widgets you do not control, a short browser pass a few times a year is a sensible addition to your maintenance routine.

What you receive

• A browser and device matrix showing what was tested and on which versions.
• A defect list with screenshots from the affected browser beside the expected rendering, so the difference is obvious.
• A note of any feature your site uses that is not yet Baseline, with the browsers where it is missing.
• Retest results after fixes, as quoted.

What this service does not cover

We test the browsers in the agreed matrix. A browser outside it may behave differently, and we do not claim otherwise. Very old browsers that no longer receive security updates are outside the default scope unless your data shows they matter. Browser testing is not a performance review, although we note obvious slowness when we see it; the performance checks service covers speed properly.

When to book cross-browser testing

• Before any launch, as part of a pre-launch QA review or on its own.
• After a redesign or a change of theme, when new CSS and JavaScript have arrived together.
• When support messages mention a problem nobody on the team can reproduce. The visitor may simply be using a different browser.

Questions about browser testing