Quick answer: Browser compatibility testing checks that your website looks right and works properly in the browsers and devices your visitors use. Start with your analytics to build a browser support list, test key pages and tasks on real phones and in cloud testing services, use tools like Can I Use, Autoprefixer and feature detection to avoid problems during development, and fix issues with progressive enhancement rather than browser-specific hacks. Repeat the core checks before every major release.
Why sites still break between browsers
Browsers are far more consistent than they were a decade ago. Chrome, Firefox, Safari and Edge all follow web standards closely and update frequently. Yet sites still break, usually because:
- A newer CSS or JavaScript feature is not supported in an older browser still in use
- Safari, especially on iPhone and iPad, handles some features differently or later than other browsers
- Older corporate machines still run Internet Explorer 11
- Form controls, fonts and scroll behaviour vary between operating systems
- Third-party scripts behave differently, or are blocked by privacy features
There has been a notable change this year. Microsoft released the new Edge, built on Chromium, in January 2020. Over time that should reduce Edge-specific issues, but many machines still run the older Edge or Internet Explorer for now. Our post on Internet Explorer support covers how to decide what to do about IE.
Step 1: Build a browser support list from data
Do not guess which browsers to support. Look at Google Analytics under Audience, Technology, Browser and OS, and Audience, Mobile, Devices for the past six to twelve months.
From that data, create tiers:
- Tier 1, full support: browsers with meaningful traffic or revenue. Everything should look and work as designed.
- Tier 2, functional support: browsers with small but real usage. Everything should work, but small visual differences are acceptable.
- Tier 3, basic access: very old or rare browsers. Content should be readable and key actions possible, even if the design is simpler.
A B2B site serving large companies may still see Internet Explorer in Tier 1 or 2. A consumer site may see mostly mobile Safari and Chrome. Your list should reflect your audience, not general web statistics.
Review the list at least once a year.
Step 2: Prevent problems during development
Most compatibility issues are cheaper to avoid than to fix.
Check support before using a feature
Can I Use shows which browsers support a given CSS, HTML or JavaScript feature. MDN Web Docs includes compatibility tables on most reference pages. Check them when you reach for something new, such as CSS Grid, newer JavaScript syntax or new image formats. Our post on CSS Grid covers fallbacks for older browsers.
Use build tools that match your support list
- Browserslist lets you define your supported browsers once in your project
- Autoprefixer adds vendor prefixes to CSS based on that list
- Babel converts modern JavaScript into a version older browsers understand
When the support list changes, these tools adjust their output automatically.
Feature detection, not browser detection
Check whether a feature exists rather than which browser is running. In CSS, @supports applies styles only when a feature is supported. In JavaScript, test for the feature before using it, or load a polyfill only when it is missing. Browser detection based on user agent strings is fragile and often wrong.
Progressive enhancement
Build the core content and actions with well-supported HTML and CSS, then add enhancements for browsers that can handle them. If a fancy animation fails in an older browser, the page should still work. This approach prevents the worst type of compatibility issue: a page that is blank or unusable.
Step 3: Test on real devices and in the cloud
Real devices
There is no full substitute for testing on real hardware, especially phones. At minimum:
- A recent iPhone with Safari
- A mid-range Android phone with Chrome
- A Windows laptop with Chrome, Firefox and Edge
- A Mac with Safari
Real devices reveal touch behaviour, performance on slower hardware and font rendering that emulators miss.
Cloud testing services
Services such as BrowserStack, Sauce Labs, LambdaTest and CrossBrowserTesting give you access to hundreds of real browsers and devices from your own browser. They are ideal for checking older versions, Internet Explorer and devices you do not own. Many also offer screenshots across many browsers at once and automated testing with Selenium.
Developer tools
Browser developer tools include device emulation, which is useful for quick layout checks at different widths. Treat it as a first pass, not a final test.
Step 4: Decide what to test
Testing every page in every browser is rarely practical. Focus on:
- Templates: homepage, a standard content page, a blog post, a listing page, a product page
- Key tasks: navigation, search, contact forms, sign-up, checkout and login
- Interactive components: sliders, accordions, tabs, menus, modals and maps
- Media: video embeds, image galleries and background images
For each, check layout, readability, interactions, forms and error messages. Keep a simple test script so testing is consistent each time. Pair it with user testing on key tasks when you can, since real people find problems that checklists miss.
Step 5: Automate where it pays off
For larger sites or frequent releases:
- Automated functional tests with Selenium WebDriver, run against several browsers in a cloud grid
- Visual regression testing tools such as BackstopJS or Percy, which compare screenshots before and after a change and highlight differences
- Linting for CSS and JavaScript that flags unsupported features based on your Browserslist settings
Automation catches regressions early, but it does not replace a human look at the main pages before launch.
Common issues and fixes
- Layout breaks in Internet Explorer: often caused by CSS Grid or Flexbox bugs. Provide a simpler fallback layout using @supports, or limit Grid to enhancements.
- Sticky elements and fixed headers misbehave on iPhone: test scroll behaviour on real iOS devices and avoid complex fixed positioning.
- Fonts look different: operating systems render fonts differently. Choose sensible fallback fonts and check line heights; see our post on web typography.
- Form inputs look or behave differently: date pickers and select boxes vary by browser. Test them and provide clear labels and validation.
- JavaScript errors stop the page working: one error in an older browser can break everything after it. Check the console in each browser and transpile modern syntax.
- Images not showing: newer formats such as WebP are not supported everywhere yet. Serve fallbacks with the picture element.
- Third-party widgets fail: privacy features in Safari and Firefox can block some trackers and embeds. Make sure the page still works without them.
Making compatibility part of the process
- Agree the browser support list at the start of each project and include it in the contract or brief
- Set up Browserslist, Autoprefixer and Babel from day one
- Test in at least two browsers during development, not only at the end
- Run the full test script before each major release
- Log bugs with browser, version, device and steps to reproduce
FAQ
Do I still need to test in Internet Explorer?
Only if your analytics show meaningful use. Many B2B and public sector sites still do. If so, aim for functional support rather than pixel-perfect design.
Is testing in Chrome enough because Edge now uses Chromium?
Not yet. Many users still have the older Edge, and Safari and Firefox use different engines. Test each engine your visitors use.
How often should I test?
Run quick checks during development and a full set before each major release or redesign. Recheck after big browser updates if something looks off.
Work for every visitor
Good browser compatibility testing is about knowing your audience, building sensibly and checking what matters. If you want a site that is built and tested to work for all your visitors, see our Turn visitors into customers service.
