Test my website on all browsers before launch

The owner usually tests in the browser they use every day, which is often Chrome or Edge on a laptop. Those two share one rendering engine, so a page that works in one often works in the other, and the owner reads that as the page working. Safari and Firefox each run their own engine. A detail that one engine handles differently can change the height of a button, wrap a menu onto two lines or hide a row of cards. The owner never sees it, because the page looks right where they built it.

• Open the homepage and the sign-up or checkout page in Safari and Firefox, not only Chrome.
• Look for a button that wraps to two lines, a menu over the first heading, or a card that stretches past its neighbor.
• On an iPhone, tap play on each video. A video without the playsinline attribute can open in the full screen player.
• Turn on page translation or a tracker blocker, one at a time, then tap the main button.

Engines follow the same specifications, but they ship features and fix bugs at different times, and the gaps show up in small places. The default padding inside a text box, the arrow a select element draws and the way an element with no set width shrinks inside a row can all differ. A visitor sees these as a button that wraps or a row that spills past the edge. Each one passes in the engine you built on, which is why the bug seems to come from nowhere.

Video and touch follow a separate set of rules. On an iPhone, Safari will not autoplay a video with sound, and a video element without the playsinline attribute opens in the full screen player. A hero video that loops quietly in Chrome can show a still frame or a play icon on the phone. Check the first screen on an iPhone with the video in view, then tap play and see whether the page responds.

Some differences come from what the browser does to the page before your code runs. Chrome can translate a page into the visitor's language by rewriting its text. A React app that later looks up a text node by its old content can throw an error, and the button stops responding. A browser that blocks trackers by default, such as Brave with its shields on, stops scripts from known analytics and chat domains. The Console shows the difference: a DOM error after a language change, or a request for a foreign domain that never finishes.

Test the signup flow

Use one step as the unit: the homepage, the product page or the sign-up form. Run it in each browser, note where each run stops, and compare the screenshots at that step. If the Add to bag tap works in Chrome and Firefox and does nothing in Safari, open Safari's Console after one tap and read the first error. The cause is often a script Safari runs in a different order, or a setting in that browser. If every browser stops at the same step, look at your own code first, because the fault is probably shared. A simulated run adds the visitor's view, with a screenshot and any console error for each stop.

Every new script, widget or video changes what each engine has to handle. Run the same step in each browser after a release, and again when a preview goes up. Behind a login, a paid run can use a test account and a site password or bypass secret, so the browsers reach the pages behind it.