Cross-Browser Testing: What Actually Needs to Be Tested?

A full-screen hero section is built to fill exactly the height of the viewport, height: 100vh, tested in Chrome on a laptop, looking clean, nothing cut off, nothing overflowing. It ships. Within a day, a handful of mobile users report the page looking "broken," content cut off at the bottom, a chunk of empty space where there shouldn't be one. Nobody on the team can reproduce it, because nobody on the team is testing on an iPhone in Safari, where 100vh famously includes the space behind the browser's address bar, a region that isn't actually visible, producing exactly the cut-off layout being reported. The team spent real time testing the feature. They just never tested it anywhere it was actually going to break.

That's the shape most cross-browser bugs take: not a feature that's untested, a feature that's thoroughly tested in exactly one environment, while the environment where it actually fails never got looked at.

The Real Question Isn't "Which Browsers," It's "Which Engines"

There are a lot of browser names, but far fewer rendering engines underneath them. Chrome, Edge, Brave, Opera, and most Android browsers are all built on Chromium and its Blink rendering engine. Safari, on both desktop and iOS, runs WebKit, and critically, every browser on iOS, including Chrome for iOS, is required by Apple's platform rules to use WebKit under the hood, regardless of what it's called. Firefox runs its own engine, Gecko.

That collapses "test every browser" into a much more tractable and more honest question: test the handful of engines that actually render the page differently, not the long list of browser brand names that mostly share an engine underneath. Testing Chrome and Edge separately on desktop tests the same rendering engine twice; testing desktop Safari and iOS Safari separately is testing two genuinely different environments, since mobile WebKit has real behavioral differences from its desktop counterpart beyond just screen size.

Layout and CSS, Where Most Real Bugs Live

The most common and most disruptive cross-browser issues are rendering differences: a CSS feature supported in one engine and not another, or supported with different default behavior. 100vh on iOS Safari is the classic example, but the broader category includes flexbox and grid edge cases that render subtly differently across engines, default form control styling that varies significantly between Chromium and WebKit, and newer CSS features that land in one engine's stable release well before another's.

What to actually test: render the actual layout, not just check a caniuse.com table, in each of the engines that matter for the product's real traffic. A property being "supported" according to a compatibility table doesn't guarantee it's supported with identical visual results, spacing, alignment, and default styling can all diverge even when a feature is nominally available everywhere.

Form Controls and Native Input Behavior

Native form elements, date pickers, select dropdowns, file inputs, number steppers, are rendered by the browser itself, not by the page's own CSS, which means their appearance and behavior can differ substantially across engines in ways a developer working exclusively in one browser never encounters. A custom date range that works perfectly with Chrome's native date picker can behave completely differently against Safari's, which has historically lagged on certain input types and handles some of them with meaningfully different interaction patterns.

What to actually test: every native form control actually used on the page, filled in and submitted, in each engine, not just visually inspected. A date picker that looks fine but submits a differently formatted value, or a file input that behaves unexpectedly with drag-and-drop, is the kind of bug that only shows up when the control is actually used, not just rendered.

JavaScript API Availability and Timing

Most modern JavaScript runs consistently across engines, but newer APIs can land at different times, and some long-standing differences persist around things like how different engines handle certain event timing, intersection observers near their initial edge cases, and specific Web APIs that are implemented with subtly different behavior rather than being entirely missing.

What to actually test: anything that depends on a relatively recent browser API, and anything with precise timing dependencies, scroll-triggered animations, intersection-based lazy loading, should be exercised directly in each target engine rather than assumed to behave identically because it works in the primary development browser.

Storage, Cookies, and Privacy Behavior

This is a category that's easy to overlook because it has nothing to do with visual rendering. Safari's Intelligent Tracking Prevention (ITP) restricts third-party cookies and limits how long certain client-side storage persists in ways Chrome and Firefox don't by default, which can silently break analytics integrations, embedded widgets, or any cross-site authentication flow that assumes cookies behave uniformly everywhere.

What to actually test: any feature relying on third-party cookies, cross-site storage, or persistent client-side state should be explicitly tested in Safari specifically, since it's the engine most likely to restrict behavior other engines allow by default, and a feature failing silently due to a blocked cookie often produces no visible error at all, just a feature that quietly doesn't work.

Mobile-Specific Behavior Beyond Screen Size

Responsive design testing often stops at resizing a desktop browser window, which catches layout breakpoints but misses behavior that's specific to an actual mobile browser: touch event handling versus mouse events, how position: fixed elements behave when the mobile keyboard opens, viewport units behaving differently around the dynamic toolbar on mobile Safari, and momentum scrolling interacting with custom scroll containers in ways a resized desktop window never exercises.

What to actually test: core interactive flows, not just layout, on an actual mobile browser or a reasonably accurate emulation of one, since the meaningful differences here are often about touch and viewport behavior, not just how elements are arranged at a given width.

A Practical Way to Scope This

Testing every browser version released in the last five years isn't realistic, and it isn't useful, since most of those versions share an engine with a current one and the differences that matter are overwhelmingly engine-level, not patch-version-level. A more realistic approach: identify the engines actually represented in real traffic, usually some mix of Blink (covering most desktop and Android usage) and WebKit (covering all of iOS and desktop Safari), with Gecko included if Firefox represents a meaningful share, and focus testing effort there, rather than spreading it thin across a long list of browser names that mostly duplicate each other underneath.

// playwright.config.ts
export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'mobile-safari', use: { ...devices['iPhone 13'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
  ],
});

Running the same critical-path tests across these projects catches the engine-level differences that actually matter, without requiring a separate test run for every named browser that happens to share Blink or WebKit underneath.

Final Thoughts

The hero section wasn't broken because nobody tested it. It was broken because the team's one testing environment happened to be the one environment where the bug didn't exist. Cross-browser testing done well isn't about chasing every named browser in existence, it's about recognizing that a handful of actual rendering engines, each with real behavioral differences in layout, forms, storage, and mobile interaction, account for nearly everything that breaks, and testing deliberately in each of them instead of repeatedly in one.