What Is Cross Browser Testing? Three Engines, Not Twenty Browsers

Cross browser testing is checking that your site works in the browsers your visitors actually use, rather than in the one on your desk. That definition is unglamorous and complete, and almost every article on the subject then hands you a grid of thirty browser-and-version combinations, which is where the practice starts going wrong.

Start from the engines instead. There are three that matter: Blink, which is Chrome, Edge, Opera, Brave and most of the rest; WebKit, which is Safari everywhere and every browser on iOS regardless of the name on it; and Gecko, which is Firefox. Chrome and Edge disagreeing about your layout is rare, because they are the same rendering engine with different chrome around it. Chrome and Safari disagreeing is ordinary.

Testing thirty browsers is mostly testing Blink thirty times.

What actually differs now

The vendor-prefix era is over, and the differences that remain are different in kind. Four categories cover nearly all of them.

• Codecs and media. The most expensive category, because it fails completely rather than cosmetically. A video the browser cannot decode is not a degraded video; it is an error message.
• APIs that one engine has not shipped. Feature detection is the answer, and the failure mode is a feature that silently does nothing rather than a page that looks wrong.
• Layout edge cases. Fewer than there used to be, but the ones left tend to be in the newer parts of the spec, exactly where people reach for the new thing.
• Release cadence. Safari’s engine updates ride with the operating system, so “latest Safari” is a statement about how recently somebody updated their Mac or phone.

The categories are worth naming because they need different responses. Codecs need a fallback shipped in the page. Missing APIs need detection. Layout needs looking at. Cadence needs your analytics.

A worked example, and it was ours

Our extension records video in VP9 inside a WebM container. Safari has no VP9 decoder. The share page handed the browser a single source built from the stored file’s own type, and an HTML video element given one source it cannot play does not degrade - it fails.

So for a while, a link sent to somebody on a Mac showed them the word Error. The whole promise of the product is a link another person can open, and for one engine that promise was broken.

Three things about how that went undetected are typical of the category, which is why it is worth writing down rather than quietly fixing.

What we had

Automated tests, all passing, all running in Chrome. Nothing logged an error, because from the server's point of view nothing failed - a file was served, and the browser could not use it

What would have caught it

Opening one shared recording in Safari, once. No tooling required, and no suite would have needed to exist

The person who found out was the recipient. The person who sent the link never knew, because nothing tells you the page you shared did not work for the person you shared it with. That is the defining property of cross-engine failures: they are invisible from where you are standing.

The fix was to encode an H.264 copy beside every upload and offer both sources, and then to record MP4 directly wherever the browser allows.

Where to start, which is not a matrix

Two inputs decide your list, and neither is a guess.

Your analytics. Not global market share. The browsers your visitors use, in your countries, on your pages. A B2B tool in Germany and a consumer site in Brazil have different answers, and both differ from the worldwide figures every comparison article quotes.

Your error tracking. Errors grouped by browser will tell you where things are already breaking, which is a better prioritisation than any guess about where things might.

From those, a working shape: smoke test on all three engines, test deeply on your top two. The smoke test is the same idea as anywhere else - can you load the page, sign in, complete the one flow that matters - and doing it on Safari and Firefox catches the whole codec-and-missing-API category in minutes.

Say the matrix out loud in your test plan, including what is out of scope. “We do not test Firefox on Android” is a decision when written down and an accident when not.

What the tools do and do not cover

The commercial services rent you machines with browsers on them, which solves the real problem that you cannot run Safari on Linux and cannot run every iOS version on your desk. That is worth paying for when you need it.

What they do not solve is knowing what to look at. A screenshot of your page in twelve browsers is twelve screenshots somebody has to compare, which is the problem visual regression testing exists to automate - and that suite has the same blind spot, because it only checks the browsers you told it about.

Automation of any kind is also poor at the failure that matters most here. A video that will not play, a font that does not load, a date input that renders as a text box on one engine: these pass every assertion about the DOM, because the DOM is fine. It is the rendering that is not.

The reports are the other half

However good the matrix is, some engine, some version, some device you did not test will produce a bug for a real person. The question is whether you find out.

That is the argument for making it easy to report from wherever somebody is, and for the report to carry the browser and version without asking the reporter to know them. “It doesn’t work on my phone” costs a day. “Safari 26.1 on iOS, the recording shows the video area blank, console says the source is not supported” costs an afternoon, and the difference is entirely in what the report carried, not in what the reporter knew.

Which is the honest limit of this article: cross browser testing narrows the gap, and the reports that arrive from the browsers you did not cover are how you find out where the gap still is. Neither replaces the other, and a team doing only one of them has half a picture.