Cross-browser testing has an unhelpful reputation, mostly earned during the years when supporting Internet Explorer meant rewriting half your CSS. Modern browsers agree with each other far more than they used to.
They still don't agree entirely — and the places they diverge are, annoyingly, the places users actually notice: forms, dates, video, scrolling, and anything involving Safari.
Here's a checklist that fits a small team's budget.
Let your analytics choose the browsers
Testing "all browsers" is neither possible nor useful. Open your analytics, sort by sessions, and cover what's actually there.
For most sites that means:
- Chrome — desktop and Android
- Safari — desktop and iOS, and these behave differently from each other
- Firefox — desktop
- Edge — desktop
- Samsung Internet — significant on Android in many markets
The rule of thumb: cover everything above roughly 2% of your traffic, plus anything your specific audience over-indexes on. A B2B SaaS with corporate customers may need Edge coverage far beyond its general market share. A consumer site in a mobile-first market may barely need desktop Firefox.
iOS Safari deserves special attention. Every browser on iOS uses Safari's engine underneath, so "Chrome on iPhone" is Safari wearing a different icon. If your traffic skews mobile, iOS Safari is not one browser among five — it's most of your risk.
What actually breaks
You don't need to re-test everything everywhere. These are the areas where browsers genuinely diverge:
Form controls. Date pickers, selects, file inputs and validation messages are styled and behave differently in every browser. Custom-styled forms are the single most common source of cross-browser bugs.
Sticky and fixed positioning. Especially in combination with scrolling containers, and especially on iOS.
Viewport height on mobile. 100vh on iOS Safari historically included the address bar area, producing content hidden behind browser chrome. Anything full-height needs checking on a real phone.
Video and audio. Autoplay policies, supported codecs and inline playback differ. iOS is the strictest.
Fonts. Rendering weight and antialiasing differ enough between platforms that a thin weight can be elegant on macOS and illegible on Windows.
Scroll behaviour. Smooth scrolling, scroll snapping and momentum are inconsistent.
Newer CSS. Anything recent enough that you had to check support before using it deserves a look in your oldest supported browser.
Focus states. Keyboard focus rings vary, and are easy to accidentally remove — which is an accessibility problem as much as a compatibility one.
Test on real devices where it counts
Emulators and responsive-design mode are fine for layout. They lie about three things: touch behaviour, performance, and iOS Safari's quirks.
Practical compromise for a small team:
- Real devices for iOS Safari and one mid-range Android. Beg or borrow if you don't own them.
- Real browsers on desktop — install Firefox and Edge, it costs nothing
- Emulation for breakpoint checks and quick layout passes
- A cloud testing service only if you support a genuinely wide matrix
One real iPhone catches more bugs than any amount of desktop emulation.
The checklist
Run this per browser, on your critical pages:
- Layout holds at the primary breakpoints — no overflow, no overlap
- No horizontal scrolling on mobile
- Navigation opens, closes and traps focus correctly
- Forms submit, and validation messages appear and are readable
- Date and file inputs work and are usable
- Custom selects and dropdowns open and are dismissible
- Images and video load and play
- Fonts render at readable weight
- Sticky elements stick, and don't cover content
- Full-height sections aren't cut off by browser chrome
- Hover states have a sensible touch equivalent
- Keyboard navigation reaches everything, with visible focus
- The console is free of errors
- The primary conversion path completes end to end
That last item is the one to run first if you're short on time. A misaligned footer in Firefox costs you nothing; a checkout that fails in Safari costs you everything.
Report findings so the browser is never in doubt
Cross-browser bugs have a specific reporting problem: the browser is the bug. A report that omits it is close to useless, and "it's broken on mobile" could mean any of a dozen environments.
This is where automatic capture earns its place. When a tester clicks the element in pinreview, the report carries the exact browser and version, the OS, the viewport size, a screenshot of that rendering, the CSS selector and any console errors — without the tester having to know or type any of it.
For a bug class defined entirely by environment, capturing the environment automatically isn't a convenience. It's the difference between a reproducible ticket and a guessing game.
Fit it into the release process
Cross-browser testing works best as a defined step rather than an occasional heroic effort:
- Build and self-test in your primary browser
- Run this checklist on your top three browsers before staging
- Run the full matrix during pre-launch QA, alongside your website QA checklist
- Spot-check the critical path after each production deploy
Steps one and two catch most things at the point where fixing them is cheap.
The bottom line
Cross-browser testing is narrower than its reputation. Cover the browsers your analytics actually show, focus on the handful of areas where engines genuinely diverge, use a real iPhone, and always test the conversion path first.
Then make sure every bug that comes back names its own environment — because that's the only detail that makes this class of bug fixable.