Cross-browser testing in 2026, with Baseline as a guide

Cross-browser testing used to mean long lists of old browser versions and painful workarounds. Modern browsers update themselves, follow shared standards closely, and agree on far more than they used to. The job has changed rather than disappeared: it is now about choosing a sensible set of browsers, knowing which features on your site are new enough to carry risk, and checking the places where browsers still behave differently.

Step 1: let your analytics choose

The best guide to which browsers matter is your own visitor data. If you have analytics from an existing site, list the browser and operating system combinations by share of visits, and include every combination above a threshold you agree, such as one or two percent. Keep the list in the test plan so everyone knows what "tested in all browsers" means for this project.

For a new site with no data, use a default set that covers each major engine on the platforms where it is used:

Test the current release of each. If your audience includes organisations with managed computers, ask whether they run an extended support version of a browser, which can lag behind the current release.

Step 2: understand Baseline

Baseline is a status given to web platform features to show how widely they work. web.dev describes two levels:

• Newly available: the feature is supported by all of the core browsers. In web.dev's words, it is "therefore interoperable".
• Widely available: 30 months have passed since the feature became newly available.

The core browser set behind Baseline is Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS. A feature that is not yet newly available has limited availability, which means at least one of those browsers does not support it.

Baseline status appears on MDN reference pages and in a growing number of developer tools, so you can check a feature quickly.

Step 3: list the features your site depends on

Ask your developer for a short list of the newer CSS, JavaScript and HTML features the site uses. Things like container queries, the :has() selector, popovers, dialog elements, view transitions, or newer form controls are worth naming. Then check each one:

• Widely available: low cross-browser risk. Test normally.
• Newly available: works in current core browsers, but visitors on older versions may not get it. Check what happens when it is missing: does the page fall back sensibly?
• Limited availability: at least one core browser lacks it. Test the fallback in that browser deliberately, and decide whether the feature is worth it.

This step turns cross-browser testing from a guessing game into a targeted exercise. You spend time where the risk is.

Step 4: test the places browsers still differ

Even with shared standards, some areas reward a careful look in every browser on the list:

• Form controls. Date and time pickers, file uploads, autofill, number inputs and validation messages look and behave differently across browsers and platforms.
• iPhone specifics. The address bar that hides on scroll changes the viewport height, which affects full-screen sections and fixed headers. Zoom on focus can happen when form fields use small text.
• Fonts and text. Line heights, font smoothing and text wrapping vary slightly, which can push a button label onto two lines or overflow a card.
• Media and embeds. Video autoplay rules, picture-in-picture, embedded maps and third-party widgets.
• Scrolling and overflow. Elements that scroll inside other elements, scroll snapping, and sticky positioning.
• Printing, where visitors are expected to print pages.

Step 5: record what was tested

Write down the exact browser versions, operating systems and devices used, and the date. Browsers update on their own schedules, so "tested in Safari" is only meaningful with a version. The record also tells the next person what has already been covered.

Real devices or emulators?

Both, for different jobs. Responsive design modes in desktop browsers are quick for checking layout at many widths. They are not phones: they do not reproduce touch, on-screen keyboards, real performance, or how mobile browsers resize the viewport. Cloud device services sit in between and are useful for widening coverage. For the core set, test on real hardware where you can, and say in the report when a finding comes from emulation.

What about automated cross-browser testing?

Automated tests that run the same script in several browsers are valuable on sites that change often, because they catch regressions quickly. Visual comparison tools can flag layout differences across many pages. Neither replaces a person checking whether a menu is usable or a form makes sense. Our guide to manual and automated testing looks at where each approach fits.

Browser settings that change behaviour

Two people using the same browser version can still see different results, because settings and extensions change how pages behave. When a defect cannot be reproduced, check these before closing it:

• Content blockers and privacy extensions. They can remove scripts, embeds and even cookie banners, which can break forms that depend on a third-party service.
• Strict tracking protection. Firefox, Safari and Edge each have tracking protection features that can block third-party resources by default, which affects embedded maps, video and some payment widgets.
• Text size and zoom. Larger default text sizes, set in the browser or the operating system, expose layouts that assume a fixed font size.
• Dark mode and forced colours. Some sites look broken when the operating system asks for a dark theme or high-contrast colours. Windows contrast themes are worth a quick look if your audience includes people who use them.
• Reduced motion. Visitors who ask their system for reduced motion should not get large animations; check that the site respects the preference.
• Language and region. Date formats, decimal separators and translated browser interfaces can affect forms that parse dates or prices.

Recording the settings used for each test, along with the browser version, makes these differences easy to spot later.

Keeping the browser list current

The browser list is not fixed for the life of a site. Review it when you review analytics, perhaps once or twice a year, and when something changes in your audience, such as a new market or a campaign aimed at mobile users. Remove combinations that have fallen below your threshold, add new ones that have risen above it, and note the date of the change in the test plan. A list that matches last year's audience tests the wrong things with great care.

A short cross-browser routine

1. Agree the browser list Use analytics, or the default set, and write it into the test plan.
2. Check feature status List newer features the site uses and look up their Baseline status.
3. Test key flows in every browser Forms, navigation, checkout or booking, on desktop and mobile.
4. Spot-check templates Every template at least once per browser; look at the risky areas above.
5. Record versions Browser, version, operating system, device and date for every finding.
6. Retest fixes In the browser where the defect appeared, and in one other to catch side effects.

Sources

• Baseline, web.dev

Sources were read on 4 November 2026.