Cross-browser Testing

It’s Friday evening and a food delivery website launches its brand-new checkout. The team tested it all week: on their laptops, in Chrome, it was perfect. By 9 pm the support inbox is on fire. “I can’t find the Order button.” “The time picker does nothing.” Almost every complaint comes from an iPhone. In Safari, the Place order button sits hidden under the browser’s toolbar, and the delivery time picker throws a JavaScript error. Nobody had opened the page on an iPhone before release.

That’s what cross-browser testingCross-browser testingChecking a website works and looks right in different browsers and browser versions.Open in glossary → is for: making sure your website works for people using other browsers than the one on your desk.

Why it matters

• Your users don’t all use Chrome. On phones, Safari has a huge share in many countries (every iPhone user has it), and Samsung Internet comes preinstalled on millions of Galaxy phones.
• Browser bugs hit whole groups of people. If checkout fails in Safari, it fails for every iPhone user, which can be a third or more of your customers.
• Developers usually work in one browser. Most front-end code is written and checked in Chrome. Testers are often the first people to open it anywhere else.
• The bugs are invisible in “your” browser. You can’t find a Safari-only bug by testing harder in Chrome.

Cross-browser testing is one part of compatibility testingCompatibility testingChecking the product works across different devices, OS versions, browsers and screen sizes.Open in glossary →, which also covers devices, OS versions and screen sizes. (Screen sizes get their own lesson: Responsive Design Testing.)

Browsers vs rendering engines

A browser is the app you open: Chrome, Safari, Edge. Inside every browser is a rendering engine that turns HTML and CSS into pixels, plus a JavaScript engine that runs the scripts. There are many browsers, but only three engines that matter today:

Engine	Made by	Browsers that use it	JavaScript engine
Blink (Chromium)	Google + others	Chrome, Edge, Opera, Samsung Internet, Brave, Vivaldi	V8
WebKit	Apple	Safari on Mac, iPhone and iPad, plus every other browser on iOS	JavaScriptCore
Gecko	Mozilla	Firefox (on desktop and Android)	SpiderMonkey

What this means for your testing:

• Browsers that share an engine mostly behave the same. If it works in Chrome, it very likely works in Edge and Opera.
• “Mostly” isn’t “always”. Samsung Internet is based on Chromium, but it is often several versions behind Chrome, and it adds its own features (like a content blocker and its own dark mode).
• The real differences are between engines. A good minimum set covers all three: a Chromium browser, Safari (WebKit) and Firefox (Gecko).

Why the same page looks different

All browsers follow the same web standards, so why do they disagree? Because standards leave room for interpretation, new features ship at different times, and every browser adds its own touches.

Area	What differs	Example
CSS support	New features arrive in each engine at different times	A layout uses a CSS feature that an older Samsung Internet or iOS version doesn’t know, so it falls apart
Form controls	Selects, checkboxes, sliders and file pickers are drawn by the browser or the OS	Safari on macOS draws a native pop-up button; Chrome follows the site’s styling more closely
Date and time inputs	Each browser has its own picker and format	A calendar popup in Chrome, a wheel picker on iPhone
Fonts	Different system fonts and text rendering	Segoe UI on Windows is wider than San Francisco on Mac, so a label wraps onto two lines
Autofill	Browsers paint autofilled fields in their own colors	Light blue in Chrome, yellow in Safari
Default styles	Each browser has a built-in stylesheet for margins, buttons, focus rings	Buttons and focus outlines look different unless the site resets them
JavaScript APIs	Not every API exists everywhere	The Payment Request API exists in Chrome and Safari, not in Firefox
Extensions	Ad blockers and password managers change the page	An ad blocker hides a newsletter box whose class name contains “banner”
Privacy features	Tracking protection blocks cookies and scripts	Safari’s Intelligent Tracking Prevention (ITP) and Firefox’s Enhanced Tracking Protection block or isolate third-party cookiesCookieA small piece of data a website stores in your browser, for example to keep you logged in.Open in glossary → (see Cookies, Sessions and Storage), so a login or payment widget inside an iframe stops working

Try it yourself. Here’s one delivery form as three browsers would draw it:

Same page, different browsers

One delivery form, three browsers. Switch between them and compare. Which differences are fine, and which are bugs?

Chrome · WindowsSafari · macOSFirefox · Windows

Markers Autofilledengine: Blink

Checkout · Midnight Grocer

grocer.example.com/checkout

Midnight Grocer

Free delivery after 8 pm · width: 100vw

3

Delivery details

NameAna PetrovićEmailana@example.com4

Delivery date10/24/20261

Time slot20:00 – 22:002

Groceries (14 items)€38.90

Delivery€3.90

Place order · €42.805

1. 1Date inputMinor bugChrome shows mm/dd/yyyy segments and a calendar icon. The icon is almost invisible here: the dark page never declares color-scheme: dark, so Chrome draws it in black. A small but real bug.
2. 2Dropdown (select)AcceptableChrome keeps the site’s dark styling and draws its own arrow. The opened list uses the system style.
3. 3Scrollbars & page widthBugWindows shows a classic scrollbar that takes about 15–17 px. The blue promo strip uses width: 100vw, and 100vw includes the scrollbar, so the page is slightly too wide and a horizontal scrollbar appears.
4. 4Autofill colorsBugChrome paints autofilled fields light blue. The site forces white text (-webkit-text-fill-color), so name and email turn white on light blue: unreadable.
5. 5Font renderingAcceptableThe page uses the system font: Segoe UI on Windows, a bit wider than on a Mac. Fine, as long as nothing wraps or gets cut off.

Verdict per browser

Difference	Chrome	Safari	Firefox
Date input	Minor bug	Acceptable	Acceptable
Dropdown (select)	Acceptable	Acceptable	Acceptable
Scrollbars & page width	Bug	Acceptable	Bug
Autofill colors	Bug	Bug	Acceptable
Font rendering	Acceptable	Acceptable	Acceptable

Choosing a browser matrix

You can’t test every browser, version and device. Instead, teams agree on a browser matrix (also called a support matrix): the list of browsers that must work, and how deeply each one is tested.

An example matrix for an online shop:

Tier	What it means	Browsers
Tier 1	Full testing of every feature before each release	Chrome latest (Windows, Android), Safari on iOS (latest + previous major), Safari on macOS latest
Tier 2	Main user flows (smoke test: login, search, checkout)	Edge latest, Firefox latest, Samsung Internet latest, Chrome previous version
Tier 3	“It works, but may look a bit different.” Fix only serious bugs	Older versions, Opera, other browsers with small usage

What usually breaks

These bugs show up again and again. Learn the patterns and you’ll know where to look first.

#	Bug	What you see	Typical severity
1	Layout gaps and grids	In an older browser, cards and form fields stick together or the grid collapses into one long column	Medium
2	Sticky and fixed elements	A sticky header stops sticking, or a fixed button jumps when the keyboard opens on iOS	Medium–High
3	100vh on mobile Safari	A full-height screen is taller than the visible area, so a bottom button hides under the browser toolbar	High
4	Date and number inputs	The custom date picker doesn’t open; a number field accepts “e” or changes value when you scroll	High
5	Unsupported JavaScript API	A button does nothing and the console shows is not defined or is not a function	High
6	Video autoplay	The hero video doesn’t play on iPhone (autoplay needs muted and playsinline)	Low–Medium
7	Clipboard	“Copy code” fails silently because the page isn’t on HTTPSHTTPSThe secure version of HTTP; traffic between the browser or app and the server is encrypted.Open in glossary → or the browser asks for permission	Medium
8	File uploads	An iPhone photo (HEIC format) is rejected, or the camera option is missing	Medium–High
9	Fonts	Fallback fonts make text wider, so buttons wrap or text is cut off	Low–Medium
10	Autofill styling	Autofilled fields turn light blue or yellow and the text becomes unreadable	Medium
11	Third-party cookies blocked	“Sign in with…” popups, chat widgets or payment iframes fail in Safari and Firefox	High
12	Naive browser detection	“Your browser is not supported” in a browser that works perfectly well	Medium

Find the bug

Here’s a checkout for a running-shoe shop. It works in Chrome on desktop, but it has six browser-specific bugs. Test it like a pro:

• Open the page in each browser with the buttons at the top.
• In each one, fill the form with Autofill saved address, pick a date, try Express pay and try to place the order.
• Keep an eye on the Console, just like in real DevToolsDevToolsDeveloper tools built into browsers for inspecting pages, network traffic and errors.Open in glossary → (see DevTools for Testers).
• Compare carefully: spacing, banners, what’s visible at the bottom of the screen.

🐞 Bug hunt: Running shoe checkout

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

Open the page in…

ChromeWindows desktopSafariiPhone, iOS 15.8FirefoxWindows desktopSamsung Internet 12Galaxy S10, Android 10

Autofill saved address Reload page

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36

Checkout · NightRun

nightrun.example.com/checkout

NIGHTRUN Secure checkout

Express pay

or check out below

Contact & delivery

Full nameEmailStreet address

Delivery date

Choose date

Shipping

Standard3–5 daysFreeExpressNext day$9.00

We accept

CardWalletBank transferGift card

Night Sprint 3 · EU 42$129.00

ShippingFree

Total$129.00

Place order

Console

• › Navigated to https://nightrun.example.com/checkout

1. 1

   Hint: Open the page in Safari on the iPhone and choose a delivery date. Watch the console.

   Safari on iOS 15: the delivery date picker does nothing

   Tapping Choose date throws TypeError: dateInput.showPicker is not a function. The showPicker() method only exists from Safari 16, so on iOS 15 the field is unusable and the order can't be completed. Expected: check that the method exists, and fall back to the native date input.

   Reveal answer✓ I found this
2. 2

   Hint: In Safari on the iPhone, look at the very bottom of the screen. Can you place the order?

   Safari on iOS: "Place order" is hidden under the browser toolbar

   The bottom bar is positioned at the bottom of a 100vh container. On iOS Safari, 100vh is the screen height as if the toolbar were hidden, so the box is taller than the visible area and the bar ends up behind Safari's address bar and only a thin strip shows. Expected: the button is fully visible and tappable (fix with 100dvh or env(safe-area-inset-bottom)). Severity: blocker for iPhone users.

   Reveal answer✓ I found this
3. 3

   Hint: Try Express pay in each browser and compare the console.

   Firefox: Express pay does nothing (Chromium-only assumption)

   In Firefox the button silently fails with ReferenceError: PaymentRequest is not defined. The Payment Request API is supported in Chrome, Edge, Samsung Internet and Safari, but not in Firefox. Expected: use feature detection and hide the button or offer normal card payment when the API is missing.

   Reveal answer✓ I found this
4. 4

   Hint: Compare the spacing between sections in Samsung Internet and in Chrome.

   Samsung Internet 12: fields, sections and cards stick together

   The layout uses the flexbox gap property, which arrived in Chromium 84. Samsung Internet 12 is based on Chromium 79, so all the spacing disappears: inputs touch each other and the shipping cards merge. Expected: correct spacing in every browser in the matrix (or a fallback using margins).

   Reveal answer✓ I found this
5. 5

   Hint: Use "Autofill saved address" in Chrome, Safari and Firefox and compare the fields.

   Autofilled fields become unreadable

   The site forces white text with -webkit-text-fill-color, but the browser paints autofilled fields with its own background: light blue in Chromium browsers and yellow in Safari. White on light blue or yellow is unreadable. Firefox only tints the field, so it looks fine there. Expected: readable text in every browser (style :autofill properly).

   Reveal answer✓ I found this
6. 6

   Hint: Open the page in Firefox. Is the warning true?

   Firefox: "Your browser is not supported" banner

   The page shows a warning if the user agent doesn't contain "Chrome" or "Safari". Firefox's user agent contains neither, so it gets blocked, even though the rest of the checkout works. Expected: no warning in supported browsers. Detect features, not browser names.

   Reveal answer✓ I found this

Notice the Environment line. For browser bugs, the browser name, version, operating system and device are not optional: without them, a developer can’t reproduce the bug. See Writing Bug Reports for the full format.

Tools & how-to

Real browsers first

• Install the main desktop browsers: Chrome, Firefox and Edge on your computer. Safari only runs on macOS, so you need a Mac (or a cloud service) to test it.
• Test on real phones: at least one iPhone and one Android phone, ideally a Samsung. A real deviceReal deviceA physical phone or tablet used for testing, as opposed to an emulator or simulator.Open in glossary → shows you the real toolbar, keyboard, date pickers and autofill.
• Debug Safari on an iPhone: on the iPhone, turn on Settings › Apps › Safari › Advanced › Web Inspector (on older iOS versions: Settings › Safari › Advanced). On the Mac, turn on Safari › Settings › Advanced › Show features for web developers, connect the phone with a cable, then pick it in the Develop menu. You get the full Web Inspector, console included, for the page on the phone.
• Debug Chrome on Android: turn on USB debugging on the phone, connect it, then open chrome://inspect in desktop Chrome.

Cloud device labs

Services like BrowserStack, LambdaTest and Sauce Labs let you open your site in hundreds of real browsers and devices from your own browser. They’re great for browsers you don’t own: old iOS versions, Samsung phones, Windows-only browsers from a Mac. Most offer a local testing tunnel, so you can test a staging site that isn’t public.

Preview versions

Safari Technology Preview is a free app from Apple for macOS that ships upcoming Safari features early. Together with Chrome Beta/Canary and Firefox Developer Edition/Nightly, it lets you catch problems before a new browser version reaches your users.

Responsive mode is not a real browser

The device toolbar in Chrome DevTools (and “Responsive Design Mode” in Firefox and Safari) changes the size of the page and sends a different user agent. It’s still the same engine underneath. Choosing “iPhone 15” in Chrome gives you a narrow Chrome window, not Safari. It cannot show you:

• Safari’s toolbar and the 100vh problem
• iOS date pickers, keyboards and autofill
• WebKit-only CSS or JavaScript bugs
• Real fonts, real touch behavior and real performance

Use it to check layouts quickly, then confirm on real browsers.

User agent spoofing

You can make a browser pretend to be another one. In Chrome DevTools open the ⋮ menu › More tools › Network conditions, untick “Use browser default” and pick a user agent. Safari has Develop › User Agent. This only changes what the browser says it is. It’s useful for testing user agent checks (like the banner bug above) and server redirects to a mobile site, but the page still renders with your real engine, so it can’t find rendering bugs.

How to run a cross-browser pass

Example test cases

Checklist

Cross-browser testing checklist

0 of 12 checked

Copy

• I know the browser matrix (browsers, versions, tiers) and where it came from
• Tier 1 flows were tested in at least one Chromium browser, Safari and Firefox
• iPhone testing was done on a real device, not only in DevTools responsive mode
• Layouts compared side by side: spacing, alignment, grids and gaps look right
• Sticky and fixed elements (headers, bottom buttons) stay visible on mobile Safari
• Date, number and select fields work with each browser’s native controls
• Autofilled fields are readable in every browser
• Fonts load (or fall back) without text wrapping or being cut off
• No JavaScript errors in the console in any browser
• Features with limited support have a working fallback
• Login, payment and chat widgets work with third-party cookies blocked (Safari, Firefox)
• Every bug report includes browser, version, OS and device

Check your understanding

Quick quiz

0/6 answered · 0 correct

1. 1.A page works in Chrome on Android but a button is broken in Chrome on iPhone. Which browser should you also check first?

   AFirefox on WindowsBSafari on iPhoneCEdge on WindowsDSamsung Internet

2. 2.Which pair of browsers shares the same rendering engine?

   AFirefox and SafariBChrome and EdgeCSafari and EdgeDFirefox and Chrome

3. 3.The date picker looks completely different in Safari than in Chrome, but it works and saves the right date. What is it?

   AA critical bugBAn acceptable browser differenceCA security issueDA performance problem

4. 4.Why can't DevTools device mode replace testing on a real iPhone?

   AIt is too slowBIt only changes the screen size and user agent; the engine is still Chrome'sCIt doesn't support touch at allDIt needs a paid license

5. 5.Firefox users see "Your browser is not supported", but the site works for them once they dismiss it. What is the most likely cause?

   AFirefox has no JavaScript engineBA naive user agent check instead of feature detectionCThe site is not on HTTPSDThird-party cookies are blocked

6. 6.How should you decide which browsers to test?

   ATest only the browser the developers useBTest every browser ever madeCUse real analytics data to build a tiered browser matrixDTest whatever is installed on your laptop

Key takeaways

• There are three engines that matter: Blink (Chrome, Edge, Opera, Samsung Internet), WebKit (Safari and every browser on iOS) and Gecko (Firefox). Cover all three.
• Pages differ because of CSS support, native form controls, fonts, autofill, default styles, JavaScript APIs, extensions and privacy features.
• Different is fine, broken is not. Report what is unreadable, unusable, missing or against the requirements.
• Build a browser matrix from analytics, with desktop and mobile, latest and previous versions, and tiers.
• Classic bugs: gaps and sticky elements, 100vh on mobile Safari, date inputs, unsupported APIs, autofill colors, blocked third-party cookies and user agent sniffing.
• Responsive mode and user agent spoofing are not real browsers. Confirm on real devices or a cloud device lab, and always report the browser, version, OS and device.