Cross browser testing is the practice of checking that a website works across different browsers, devices and assistive technologies, using a defined target list, real test passes and feature detection rather than assumptions about what every visitor runs.
It is a standard stage in front-end web development, and this page covers what to test, which tools exist and a practical checklist to follow on each release.
What cross-browser testing covers
MDN defines the term plainly: “Cross-browser testing is the practice of ensuring that a website works across various browsers and devices.” The scope is wider than desktop browsers. MDN lists older browsers that lack recent JavaScript and CSS features, devices from desktops to smart TVs with different hardware limits, and people who rely on screen readers or use only a keyboard.
The same page contains a warning that applies to every developer: “Remember that you are not your users”. A site that behaves well on the machine used to build it can still fail elsewhere, because other people run other browsers, older versions, smaller screens and slower hardware.
Expectations matter as much as coverage. MDN says “A site doesn’t need to deliver the exact same experience on all browsers and devices, as long as the core functionality is accessible in some way.” A modern browser might show an animated effect where an older one shows a flat graphic carrying the same information. That approach, often called progressive enhancement, keeps the content reachable while still using newer features where they are available.
Deciding which browsers to support
Nobody can promise a site works everywhere. MDN is direct about it: “it’s just about impossible for a website to work on ALL browsers and devices, so a web developer should come to an agreement with the site owner on the range of browsers and devices where the code will work.” Writing that range down before development starts turns testing from an open-ended worry into a finite list.
For a general-audience site, the MDN guidance is that “The site should work entirely in the last few versions of the most popular desktop and mobile browsers”. Visitor analytics for the site itself are the better guide where they exist, because they show which browsers real visitors use, and they can justify adding or dropping an entry.
Baseline, now defined by the WebDX Community Group, gives a shared language for support decisions. The web.dev page on Baseline defines two stages: “Newly available: The feature is supported by all of the core browsers, and is therefore interoperable.” and “Widely available: 30 months have passed since the newly interoperable date.” The core browser set it names covers Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS. A feature that is widely available can usually be used without worrying about fallbacks, while a newly available one deserves a closer look at the audience.
A practical testing checklist
Testing is most effective when it happens throughout a project. MDN warns that “If you leave all the testing to the end of a project, any bugs you uncover will be a lot more expensive and time-consuming to fix than if you uncover them and fix them as you go along.” The table below turns that advice into a routine for each release.
| Area | What to check | Where to check it |
|---|---|---|
| Desktop browsers | Layout, forms, navigation and scripts | Firefox, Chrome, Edge and Safari |
| Mobile browsers | Touch targets, viewport behaviour, rotation | iOS Safari and Chrome on Android |
| Feature support | Fallbacks for newer CSS and JavaScript | The oldest browsers on the target list |
| Keyboard and screen reader | Every control reachable and announced | Keyboard only, then a screen reader |
| Images and media | Formats decode and display everywhere | Each browser on the target list |
The browser names and test areas in the table follow the MDN guide to cross-browser testing.
The first pass is cheap: MDN advises that “you should make sure there are no general issues with your code that are stopping your feature from working”, testing “in a couple of stable browsers on your system” before moving on to the rest of the target list. A bug that appears in every browser is a coding bug, not a compatibility bug, and it is quicker to find in a single browser’s developer tools.
Feature detection instead of browser sniffing
When a browser lacks a feature, the right response is to test for the feature, not to guess from the browser name. MDN describes the technique: “Feature detection involves working out whether a browser supports a certain block of code, and running different code depending on whether it does (or doesn’t)”. The result is that every browser gets a working experience even if it is a plainer one.
The page is firm about the alternative. It tells developers not to “confuse feature detection with browser sniffing”, and calls sniffing “a terrible practice that should be discouraged at all costs”. Browser names and version strings change, and a rule based on them breaks when a new browser or version appears.
CSS has its own mechanism. MDN explains that “The @supports CSS at-rule lets you specify CSS declarations that depend on a browser’s support for CSS features.” A stylesheet can provide a simple layout by default and wrap a more advanced one in a feature query, so browsers that understand it get the advanced layout and the rest keep the simple one. The same idea applies to images, where support for newer formats differs by browser, and the comparison in the guide to image formats for web is worth reading before choosing formats and fallbacks.
Tools for testing across browsers and devices
Local testing in the browsers installed on a machine is the starting point. MDN’s guidance is to start by testing in a couple of stable browsers on the developer’s own system, then widen the pass to the full target list, including the mobile browsers on phones and tablets.
Cloud services fill the gaps. According to MDN, “Commercial cross-browser testing apps like Sauce Labs and BrowserStack are based on Selenium, but allow you to access their setup remotely using an interface, saving you the hassle of setting up your own testing system.” These services provide many browser and operating system combinations without owning the devices, and they can run scripted tests on every code change.
MDN’s introduction to automated testing also recommends task runners and build scripts that handle chores such as linting and adding CSS prefixes. Automation catches regressions quickly, while manual passes remain the place to judge visual quality and the feel of interaction.
Tools such as Can I use publish browser support tables for web features, and are handy when deciding whether a fallback is needed before the first line of code is written. Always read the support data next to the browser list agreed for the project, since a feature that is fine for one audience may not be for another.
Accessibility belongs in the same pass
Assistive technology is part of the browser matrix. MDN suggests a simple first check: “Do some lo-fi accessibility testing, such as trying to use your site with only the keyboard, or using your site via a screen reader to see if it is navigable.” This takes minutes and often reveals problems that no visual check will find.
Because keyboard handling, focus order and labels vary by browser and screen reader combination, it is worth running through the guidance on web accessibility alongside the functional checks. Treating the two as one routine saves time and avoids repeating the same setup.
Frequently asked questions
How many browsers should be tested?
There is no fixed number. The range should be agreed with the site owner and written down, and should include the most popular desktop and mobile browsers plus any others that analytics show real visitors using.
Is testing in one browser enough?
No. A site that works in the browser used to build it can still fail elsewhere, so the target list should be checked in turn, using real devices or a cloud testing service where owning every device is impractical.
What is the difference between feature detection and browser sniffing?
Feature detection checks whether the browser supports a specific capability and adapts, while sniffing guesses from the browser name or version. MDN recommends the first and discourages the second.
When should cross-browser testing start?
At the start of the project and on every change. Bugs found late cost more to fix, so checks belong in the development routine rather than a final step before launch.
