Which Phones and Browsers to Test Your Website On

Short answer: Let your own analytics decide: test on the browsers and devices that make up most of your visitors, which for many small business sites means an iPhone running Safari, a mid-range Android phone running Chrome, and Chrome or Edge on a laptop. Use browser emulation for quick layout checks, but confirm anything important (forms, payments, bookings) on real phones. A 15-minute script, run after every significant change, catches most problems before customers do.

Start with your own data, not a list from the internet

Generic "top devices" lists describe the whole web. Your site has its own audience. A café's customers skew to phones; a B2B supplier may see mostly office desktops.

In Google Analytics 4, the Tech details report (Reports, then Tech, then Tech details) breaks visitors down by browser, device category, device model, operating system, OS version and screen resolution, according to Google's help page for the report. Look at the last 90 days and note:

• the split between mobile, desktop and tablet,
• the top three browsers,
• the top two or three operating systems and their versions,
• the most common screen resolutions.

Then sort by key events (enquiries, bookings or purchases) as well as by users. A device that brings few visitors but many enquiries deserves a place on your test list.

If you don't have analytics yet, a sensible starting assumption for an Australian consumer-facing site is an iPhone, an Android phone and a desktop browser, then adjust once you have data.

Why one iPhone browser covers most iPhone browsers

Apple's App Store Review Guidelines (guideline 2.5.6) say apps that browse the web must use Apple's WebKit framework, with an entitlement for alternative browser engines available only in the EU and Japan. For an Australian audience, that means Chrome, Firefox and Edge on an iPhone all render pages with the same engine as Safari. If your site works in Safari on a current iPhone, it will very likely work in other iOS browsers too. Android is different: Chrome is the usual default, but Samsung phones ship with Samsung Internet, which is worth a quick check if your analytics show it.

Emulators versus real devices

Chrome DevTools has a device mode that simulates mobile viewports, throttles CPU and network, and can fake location and orientation. It's fast and free, and ideal for checking layouts at different widths.

Google's own documentation is clear about its limits: device mode is a "first-order approximation." Your code isn't actually running on a phone, and some things, such as mobile CPU behaviour, can't be simulated. Google's advice is that when in doubt, run the page on a real device, using remote debugging to inspect it from your computer.

For iPhones, WebKit's documentation explains how: turn on Web Inspector in the phone's Settings under Safari, then Advanced, connect it to a Mac, and the phone appears in Safari's Develop menu so you can inspect the page live.

In practice:

The test matrix template

Copy this into a spreadsheet and fill it in from your analytics.

Priority 1 gets the full script every time. Priority 2 gets it for major changes. Priority 3 gets a quick look a couple of times a year.

The 15-minute test script

Run it on each Priority 1 device after any significant change.

1. Homepage (2 min): loads without layout jumping; logo, headline and main button visible without scrolling on a phone.
2. Navigation (2 min): open and close the menu; visit three pages through it; back button works.
3. Phone and email links (1 min): tap the phone number; the dialler opens with the right number. Tap the email link.
4. Main form (4 min): fill in your enquiry or booking form with real-looking data. Check the right keyboard appears (numbers for phone fields, email keyboard for email), autofill works, error messages are clear, and the thank-you page and confirmation email arrive.
5. Key page (2 min): your most important service or product page; images sharp, text readable without zooming, nothing cut off.
6. Text zoom (2 min): increase the browser's text size or zoom to 200%; nothing overlaps or disappears.
7. Sideways (1 min): rotate the phone; sticky headers don't cover half the screen.
8. Note anything odd (1 min) with a screenshot, the device and the page.

Log results in the same spreadsheet so you can see when a problem first appeared.

Free and low-cost options

• Your team's own phones. Ask staff which phones they use; you may already cover the matrix.
• Browser developer tools for layout checks in Chrome, Edge, Firefox and Safari.
• Cloud device services that stream real devices to your browser, useful for the odd model you don't own. Many have free trials; check current pricing on the provider's site.

FAQ

Do I still need to test Internet Explorer?

Microsoft has retired it, so for almost every small business site, no. Check your analytics; if it doesn't appear, don't spend time on it.

How often should I run the test script?

After any design change, plugin or theme update, or new form, and at least once a quarter even when nothing has changed, because browsers update constantly.

Is a responsive design checker website enough?

It's a quick way to preview widths, but it's effectively an emulator. Use it for layout, then confirm forms and payments on real phones.

If you'd like your test matrix filled in from your actual analytics and the first round of checks done for you, send us your site and we'll start there.

Sources

• https://support.google.com/analytics/answer/12980150
• https://developer.chrome.com/docs/devtools/device-mode
• https://webkit.org/web-inspector/enabling-web-inspector/
• https://developer.apple.com/app-store/review/guidelines/