Cross browser testing basics: why the site works on your machine and not on theirs

Different browsers render the web through different engines, and the honest answer is a deliberate support decision, never perfection everywhere.

The site was built, the owner loves it, every page looked right on the screen it was made on, and then a customer calls to say the menu does not open on their device. Nothing was changed on the site. It is exactly as it was when the team approved it. What changed is the engine reading it.

The mechanism is that each browser carries its own engine, its own way of turning code into a drawn page, and each engine has its own reading of modern web features. Most of them agree on the core: text, images, links, forms. The edges drift: new layout features, media handling, fonts, the fresher corners of the platform.

The market's false version is the sentence it worked on my machine, said as if it were a conclusion. It is a description of one machine. The web is not rendered on your machine; it is rendered on the customer's phone, on an older laptop, on a browser that has not been updated in a year, and each of those is a different reading of your code.

This is how the trap closes. Development happens on one machine with one browser, the launch looks perfect to the team that built it, and the first report of a broken page arrives from a customer whose browser was never opened once during the entire build. The failure was not that the code was bad. The failure was that a decision was never made.

The honest engineering answer is not perfection everywhere. It is a deliberate support decision. Look at your analytics and see which browsers your audience actually uses, because your audience, not the whole world, is the set that matters. Treat that set as the support contract and hold it to a high standard.

Then give the margins a policy. Older or marginal browsers should get a working if plainer version rather than a broken fancy one, which in practice means the critical paths degrade in looks instead of collapsing in function. And test home, contact, and checkout on at least one device and one browser you do not personally use, including a real phone, before you call the site done.

Guidance, not guarantees: we test the critical paths across engines as a standard part of every build we ship, and we decide support by the analytics rather than by habit. Which versions your product must carry depends on who your customers are and what your data says, and the details of any single browser quirk belong to that browser's documentation. The structure holds everywhere: decide the set, protect the core, let the edges be plain and working.