Cross-browser compatibility testing checks that a website's features and layout work consistently in every browser, browser version, operating system and device you support, and it includes fixing what breaks. General cross-browser testing is about the testing process and tools; compatibility testing is about the differences themselves: a CSS feature one browser has not shipped yet, a date picker that behaves differently on Android, or a login that fails when third-party cookies are blocked.
What is cross-browser compatibility testing?
A browser is compatible with your site when every feature you rely on is supported and renders the way you intended. Compatibility testing, often shortened to CBT, answers three questions:
- Which browsers and versions do we support?
- Does every feature we use work in all of them, or fall back gracefully where it does not?
- Did the latest browser release or our latest deployment break anything?
Wider compatibility testing can also cover operating systems, hardware, screen readers and slow networks, but for websites the browser side is where most problems appear.
Why compatibility still matters in 2026
- Your audience is split across engines. StatCounter's September 2026 figures give Chrome 66.4% of worldwide browser usage, Safari 18.3%, Edge 6.0%, Firefox 2.8% and Samsung Internet 2.3%. On mobile, Safari has 24.7%, and in the United States it has 30.4% across all devices.
- Every iPhone browser runs WebKit. Chrome, Firefox and Edge on iOS use Apple's engine (with a limited exception in the EU), so a Safari bug hits every iPhone user, whatever browser they picked.
- Features arrive at different times. New CSS and JavaScript ship in each browser on its own schedule, and older versions linger on devices that no longer update.
- Search and conversions. Google indexes the mobile version of your pages, so a layout that breaks on phones hurts both visitors and visibility.
Step 1: define your browser support matrix
You cannot support everything, so write down what you do support. Start from your analytics and group browsers into tiers:
| Tier | Typical browsers | Commitment |
|---|---|---|
| A: full support | Current versions of Chrome, Safari (Mac and iPhone), Edge and Firefox; Samsung Internet if you have Android traffic | Everything works and looks as designed; automated tests run on every change |
| B: functional | Older versions that still show up in your analytics | Core journeys work; small visual differences are acceptable |
| C: basic | Everything else | Content is readable and forms submit |
Store the matrix as a Browserslist configuration so build tools such as Autoprefixer and Babel target the same browsers. Baseline is a useful shortcut: a feature marked "Baseline widely available" has worked in all the core browsers (Chrome, Edge, Firefox and Safari on desktop and mobile) for at least 30 months, so most sites can use it without a fallback.
How to find and fix compatibility issues
- Check support before you build. Look up new features on MDN, whose pages show browser compatibility tables and Baseline status, or on Can I use. The Baseline project explains how the status is defined.
- Detect features, not browsers. Wrap newer CSS in
@supportsand check that an API exists in JavaScript before calling it, instead of guessing from the user agent string. - Build with progressive enhancement. Make content and forms work with basic HTML and CSS first, then layer newer features on top.
- Automate the routine fixes. Autoprefixer adds vendor prefixes, Babel and polyfills cover older JavaScript engines, and linters such as eslint-plugin-compat warn when code uses something your Browserslist targets do not support.
- Test in all three engines. Playwright runs the same tests in Chromium, Firefox and WebKit, and its screenshot comparisons catch layout drift.
- Confirm on real devices. Emulators and responsive design modes are fine for a first pass, but on-screen keyboards, touch, scrolling and video behave differently on real phones. Use your own devices or a cloud grid such as BrowserStack, TestMu AI (formerly LambdaTest), Sauce Labs or BitBar.
- Test with privacy protections on. Safari's tracking prevention, Firefox's strict mode and Brave's Shields can block scripts, cookies and embeds your site depends on.
Common compatibility issues in 2026
| Issue | Where it shows up | Typical fix |
|---|---|---|
| Full-height sections jump or hide behind the toolbar | Mobile browsers, especially Safari on iPhone | Use dynamic viewport units such as dvh instead of vh |
| Newer CSS features ignored | Browsers that have not shipped the feature, older devices | Check Baseline status and add @supports fallbacks |
| Date, time and select inputs look and behave differently | Every browser, which uses its own native pickers | Accept native controls or use a well-tested component library |
| Video will not autoplay or play inline | Mobile browsers and Safari | Autoplay only muted video and add playsinline for iPhone |
| Embedded logins, payments or chat widgets fail | Safari, Firefox and Brave, which restrict third-party cookies | Prefer first-party flows or the Storage Access API, and test with default privacy settings |
| Text wraps differently and buttons overflow | Different fonts and font rendering on Windows, macOS and Android | Define fallback fonts and leave room in buttons and menus |
Cross-browser compatibility checklist
- Support matrix written down and stored as a Browserslist config.
- New features checked on MDN, Can I use or Baseline before use.
- Fallbacks in place for anything that is not Baseline widely available.
- Automated tests passing in Chromium, Firefox and WebKit.
- Forms, video and scrolling checked on a real iPhone and a real Android phone.
- Logins, payments and embeds tested with default privacy protections on.
- Region-specific pages and bot checks tested from other locations and browser fingerprints (see how to test them).
- Tests re-run after every major browser release.
Frequently asked questions
Do I need compatibility testing if my website looks good in Chrome?
Yes. Chrome covers about two thirds of worldwide browser usage, but Safari alone accounts for close to a third of US visits, and every iPhone browser runs on Safari's engine. Testing only in Chrome leaves a large share of visitors unchecked.
How often should I test for compatibility?
Run automated checks on every code change and after major browser releases, and do a manual pass on real devices before significant launches or redesigns.
Is compatibility testing expensive?
It does not have to be. Playwright, Selenium and Cypress are free, and so are MDN, Can I use and Baseline data. Paid cloud grids mainly save you from buying and maintaining your own device lab.
What is the difference between cross-browser testing and compatibility testing?
Cross-browser testing is the overall process of testing across browsers, covered in our cross-browser testing guide. Compatibility testing zooms in on whether the specific features and code you use are supported, and how to fix or work around the gaps.
