Cross-browser testing means checking that a website looks and works correctly in the browsers your visitors use, on the devices they use them on. In practice that is three rendering engines (Chromium’s Blink, Safari’s WebKit and Firefox’s Gecko) across desktop and mobile. You can cover most of it for free with installed browsers, Playwright and a mobile view, and pay for cloud devices only when you need real hardware you do not own.
Which browsers to test
Start from your own analytics, not a global chart. A B2B dashboard may be used mostly in desktop Chrome and Edge, while a consumer shop may be mostly iPhone Safari. Look at browser and device reports for the last three months and cover everything above a few percent of sessions.
If you have no data yet, this set covers the engines and most real-world traffic:
| Browser | Engine | Why it matters |
|---|---|---|
| Chrome (desktop and Android) | Blink | Largest share on desktop and Android |
| Safari (iPhone, iPad, Mac) | WebKit | Every iPhone user, and most bugs that “only happen on mobile” |
| Edge | Blink | Default on Windows; usually matches Chrome |
| Firefox | Gecko | Separate engine; catches assumptions that are really Chromium quirks |
| Samsung Internet | Blink | Preinstalled on Samsung phones, with its own update cycle and dark mode |
Two engines deserve the most attention: WebKit, because of iPhone, and Gecko, because it is the only major engine that is neither Apple’s nor Google’s.
What to check in each browser
Cross-browser bugs cluster in predictable places. Work through this list on every key page:
- Layout. Flexbox and grid gaps,
position: sticky,aspect-ratio, and container queries in older browser versions. - Fonts. Web fonts load, fallback fonts have similar metrics, no invisible text while loading.
- Forms. Date and time pickers,
selectstyling, autofill colours, validation messages, the mobile keyboard type for each input. - Media. Video autoplay rules (most mobile browsers allow it only muted), image formats such as AVIF,
srcsetchoices. - Scrolling and viewport units.
100vhversus the dynamic100dvhon mobile, scroll snapping, smooth scroll, overscroll. - JavaScript APIs. Anything newer than a couple of years: check support before relying on it.
- Interaction. Hover-only menus on touch devices, focus outlines for keyboard users, tap targets.
- Dark mode and zoom. Pages at 200% zoom and with system dark mode.
Free tools that do most of the work
Install the browsers. Chrome, Edge and Firefox run on every desktop OS. Safari runs only on macOS, which is the main reason testers without a Mac need extra tools.
Check support before you write code. Baseline labels web features as “newly available” or “widely available” across the major browsers, and Can I use gives version-by-version support tables. Checking these first prevents most cross-browser bugs.
Automate with Playwright. Playwright runs the same test script in Chromium, Firefox and WebKit on Windows, macOS and Linux, and can emulate mobile devices. A short script that opens your ten most important pages in all three engines and saves screenshots will catch most regressions on every pull request.
Use mobile views for responsive checks. Mobile layout problems are often confused with browser problems. Rule them out quickly with DevTools device mode or a mobile view extension like Mobile View Extension, then look for engine-specific causes. The difference between the two tools is explained in mobile simulator extensions vs DevTools.
Use emulators for mobile engines. The Xcode Simulator gives you real iOS Safari on a Mac (guide); the Android Studio emulator gives you real Android Chrome (guide).
When paid cross-browser testing tools make sense
Cloud testing services rent real devices and many browser versions. They are worth paying for when:
- you have no Mac and need to test iPhone Safari regularly
- customers use older browser versions you cannot install side by side
- you need to test on specific phone models for a client contract
- your automated tests need to run on real mobile hardware
For a small site, a monthly plan used for a release-week check is usually enough; for occasional checks, the free trials go a long way.
A lightweight cross-browser routine
- While building: check Baseline before using a new feature; preview in a mobile view as you code.
- On every pull request: run Playwright screenshots in Chromium, Firefox and WebKit.
- Before release: click through key flows in Safari (Mac or simulator), Firefox and Chrome on Android.
- After release: watch error monitoring and analytics for errors grouped by browser.
The mobile side of the release check is covered in detail in the mobile website testing checklist.
Frequently asked questions
How can I test my website on different browsers for free?
Install Chrome, Edge and Firefox, use Playwright to run WebKit on any OS, and use DevTools or a mobile view extension for phone sizes. On a Mac, the Xcode Simulator adds real iOS Safari.
Do I still need to test in Edge if I test in Chrome?
Edge uses the same engine as Chrome, so differences are rare. A quick pass is enough, unless your audience uses Edge-specific features or enterprise policies.
What is the most common cause of cross-browser bugs today?
Using a CSS or JavaScript feature before it is supported everywhere your users are. Checking Baseline status before adopting a feature prevents most of them.