Cross-device and cross-browser testing

Your product will be used on phones, tablets and laptops of every size, in different browsers. This page helps you choose a sensible device mix, lists what typically breaks between devices, and gives you a task for your AI beta tester.

Who it’s for

  • Teams launching a site or web app to a broad audience
  • Products with users on both phones and desktops
  • Mobile app teams that also have a web version
  • Developers who only ever test in one browser

Updated 2026-10-19.

Cross-device vs responsive testing

Responsive testing checks that the layout adapts to different widths. Cross-device testing goes further: it checks that the same flows work on different kinds of devices and browsers, with touch instead of a mouse, an on-screen keyboard, different fonts and different browser engines.

A page can look perfect at 390px in Chrome on your laptop and still fail on a real iPhone, where Safari handles the viewport, inputs and media differently. A cross-device beta test is how you find those differences before your users do.

Choosing a device and browser mix

You cannot test everything, so pick a mix that covers the main differences:

  • Engines: Chromium (Chrome, Edge), WebKit (Safari, and every browser on iPhone) and Gecko (Firefox).
  • Form factors: a phone, a tablet and a laptop or desktop.
  • Operating systems: iOS, Android, Windows and macOS each bring their own fonts, pickers and permission prompts.
  • Input: touch and mouse plus keyboard.
  • Your audience: check your analytics for the devices and browsers your visitors actually use, and weight the mix toward them.

A practical starting matrix is Chrome on Windows, Safari on macOS, Safari on an iPhone, Chrome on an Android phone and one tablet. Add Firefox and Edge if your audience uses them.

How to run a cross-device test

  1. Pick the two or three flows that matter most, for example signup, the core task and checkout.
  2. Write each flow as a short test case with steps and expected results, so every device gets the same test.
  3. Run each flow on desktop first to get a baseline.
  4. Repeat on phone and tablet viewports, then on a real phone for touch, keyboard and toolbar behavior.
  5. Switch engines: run the same steps in Safari, Chrome and Firefox.
  6. Note every difference: what works on one device and not on another, with the exact device, OS and browser.
  7. Re-test fixes on the device that failed, not just on the one you develop on.

Cross-device checklist

Input and interaction

  • Menus and tooltips that open on hover also open with a tap.
  • The on-screen keyboard does not cover inputs, submit buttons or chat boxes, and fixed footers do not jump when it opens.
  • Swipes, drag and drop and long press work on touch, or have a button alternative.
  • Double-tap does not zoom when the user meant to press a button.

Browser and platform differences

  • Full-height sections are not cut off by mobile browser toolbars that change the visible height.
  • Date, time and select inputs work with each platform's native picker.
  • Fallback fonts with different widths do not cause text to wrap or overflow.
  • Videos that autoplay on desktop have a sensible fallback on phones.
  • File uploads work with each platform's picker, including photos from the phone gallery.
  • Safari-specific CSS and JavaScript issues that never show up in Chrome are checked.

State and continuity

  • Logging in on one device and then another shows the same data.
  • A cart, draft or setting saved on desktop appears on the phone.
  • Links from emails open correctly on phones, including in in-app browsers.

Example test case

Test case: Checkout on iPhone Safari
Environment: iPhone (iOS 18), Safari, portrait; test account, store in test mode
Preconditions: one product in the cart, logged in as [email protected]
Steps:
1. Open the cart and tap "Checkout"
2. Tap the "Postal code" field and enter 94103
3. Tap "Continue to payment" while the keyboard is open
4. Enter the test card 4242 4242 4242 4242, any future date, any CVC
5. Tap "Pay"
Expected: each step advances; "Pay" is visible above the keyboard;
          order confirmation page shows the test order
Actual (bug found): at step 3 the keyboard covers the button; tapping the
          visible area dismisses the keyboard but the button jumps under the
          fixed footer. Works on Chrome desktop and Android Chrome.
Severity: High (checkout blocked for iPhone users)

Mobile apps

If you also ship a native or hybrid app, test it on the phone itself through your Play Store, App Store or TestFlight link, and compare it with the mobile web version: users often switch between the two and expect the same data and features.

Common mistakes

  • Testing only in Chrome because that is what the team uses, and missing Safari bugs.
  • Using desktop browser emulation as the only "mobile" test.
  • Covering many devices with a shallow look instead of a few devices with the full flows.
  • Reporting a bug without the device, OS and browser version, so nobody can reproduce it.
  • Forgetting in-app browsers, which many visitors use when they tap a link in a social or email app.

What to fix first

  1. Blocked flows on popular devices: anything that stops signup, login or checkout on a device your analytics show is common.
  2. Engine-specific failures: features that work in Chrome but break in Safari or Firefox.
  3. Touch and keyboard friction: covered buttons, hover-only menus, inputs that are hard to use.
  4. Visual differences: font wrapping, spacing and minor rendering differences.

Reporting cross-device bugs

Always include the device or viewport, the operating system, the browser and the steps. "Checkout button unresponsive on iPhone width in Safari after the keyboard opens" is reproducible; "mobile is broken" is not.

Doing it manually vs with an AI beta tester

Keeping a drawer of test phones and repeating every flow on each one is slow, and in practice most teams check only one or two devices before a release.

An AI beta tester like betatest.ing runs the same test cases in a real browser at different viewports, on Android emulators and on real iOS devices (from an uploaded .ipa for apps), and files differences with device details, steps, severity, screenshots and screen recordings. It can run on a schedule, so a Safari-only regression shows up soon after it ships. It uses test mode for payments and never makes real purchases.

What it can't reproduce: real-world device conditions such as poor or offline networks, camera, GPS, push notifications, sensors and battery behavior. For those, and for how your product feels in someone's hand, keep some testing on real phones with real people.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Run a cross-device test of [SITE URL] on these flows: [FLOWS TO TEST]. First run each flow on desktop as a baseline, then repeat at phone (390px) and tablet (820px) viewports, and on a phone where available. Compare every step: layout, menus and anything that relies on hover, the on-screen keyboard covering inputs or buttons, full-height sections cut off, date and select inputs, fonts wrapping or overflowing, media and uploads. Note every difference between devices, even small ones. Do not make real payments or irreversible changes. Log each bug with the device or viewport, the steps to reproduce and an annotated screenshot, record any flow that breaks, and end with a table of flows by device with pass/fail and the most important fixes.

Fill in your details

Here, or later in the chat with your tester.

  • [SITE URL] Your site or web app, e.g. https://app.example.com
  • [FLOWS TO TEST] e.g. "signup, creating a project and the upgrade page"

What the AI beta tester checks

  • Each key flow on desktop, phone and tablet
  • Hover-only menus and tooltips on touch devices
  • On-screen keyboard covering inputs or buttons
  • Full-height sections and sticky elements on small screens
  • Date, time and select inputs on each device
  • Font wrapping and overflow
  • Media playback and file uploads

What you get

  • A table of flows by device with pass/fail
  • Bugs with device, steps to reproduce and annotated screenshots
  • Recordings of flows that break on a specific device
  • The most important fixes, ranked

How to run it with betatest.ing

  1. Add your site or app as a project
  2. Paste the task and list the flows that matter most
  3. Send it; the tester runs each flow on desktop, then on smaller devices
  4. Fix the device-specific bugs and re-run the affected flows

Tips

  • Weight your device mix toward what your analytics show
  • Always include an iPhone-width check: every iPhone browser uses Safari's engine
  • Test with the keyboard open on every form-heavy page
  • Keep the same flows for each run so results are comparable

Cross-device testing: FAQ

How many devices do I need to test?

Enough to cover the main engines (Chromium, WebKit, Gecko), form factors (phone, tablet, desktop) and input types (touch, mouse). Then add the specific devices your analytics show most.

Is cross-browser testing still needed?

Yes, though less than before. Browsers agree on far more today, but Safari on iPhone and older devices still cause layout and behavior differences.

Can the tester use a real phone?

It switches viewports for phone and tablet layouts and can test mobile apps on a phone from your store or TestFlight link. For touch and keyboard behavior on a website, a real-device pass of your key flows is worth adding.

What is the difference from responsive testing?

Responsive testing checks layouts at different widths. Cross-device testing checks that flows work across devices, browsers and input methods.

Which browsers should I test on?

Cover the three main engines: Chromium (Chrome and Edge), WebKit (Safari, plus every browser on iPhone) and Gecko (Firefox). Then weight your testing toward the browsers your analytics show. Safari on iPhone deserves special attention because it behaves differently from desktop Chrome in many small ways.

Is browser emulation enough for cross-device testing?

Emulation is a good first pass for layout, but it doesn't reproduce real touch behavior, the on-screen keyboard, platform pickers or each browser engine's quirks. Run your key flows on at least one real iPhone and one real Android phone, or on real devices through a testing service.

What should I fix first after cross-device testing?

Fix anything that blocks a key flow on a device or browser many of your visitors use. Next come engine-specific failures, then touch and keyboard friction, and finally small visual differences. Your analytics tell you which devices matter most.

Related beta testing guides

  • Responsive design testing — Most layouts are designed on a wide screen and break quietly on a phone. This page explains which widths to test, the layout bugs that come up again and again, and a task your AI beta tester can run at phone and tablet sizes.
  • Mobile app beta testing — Mobile apps reach testers through store testing tracks, run on hardware you do not control, and get interrupted constantly. This guide covers how to distribute a mobile beta, what to test that is specific to phones, and how an AI beta tester fits alongside your human testers.
  • Web app beta testing — Web apps fail in ways websites do not: lost state, stale data, broken sessions and actions that half-complete. This guide shows what to test in an interactive web app before real users depend on it, and gives you a task to hand to your AI beta tester.
  • Accessibility testing — Accessibility problems lock real people out of your product, and many of them are easy to find and fix. This page covers the WCAG checks a careful browser pass can do, what it cannot replace, and a ready task for your AI beta tester.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in by test type