Best Devices for Mobile Website Testing
Choose phones and tablets from your audience data, then combine quick viewport checks with real-device testing for browser-specific behavior.
There is no single best phone or tablet for testing every mobile website. Start with your own audience data and target geography. A practical baseline, when both platforms serve your visitors, is an iPhone running Safari and an Android phone running Chrome. Add an iPad when tablet traffic or tablet-specific behavior matters. Use desktop emulation for fast responsive layout work, then verify important browser and device behavior on real devices.
This approach gives you useful coverage without trying to test every device that exists. The W3C’s device-independent testing note makes the same practical point: accounting for every possible device constraint would make device-independent tests impossible. W3C: Guidelines for writing device independent tests
1. Start with your visitors
Before choosing a model, answer these questions from analytics, support tickets, and product requirements:
- Which countries or regions are important to the site?
- What share of mobile visitors use iOS and Android?
- Which browser families and supported OS versions do visitors use?
- Do visitors use tablets, foldables, or unusually narrow screens?
- Which user journeys are most important, such as checkout, sign-in, uploads, or forms?
- Does the site need to work for people using mobile assistive technology?
Choose devices that represent real visitors and meaningful differences in behavior. A screen-width preset is useful for layout coverage, but it cannot stand in for every OS, browser version, or hardware behavior. Usage varies by geography, so a model that represents one market may be a poor choice for another.
2. Build a practical starting device set
| Device category | What it helps cover | When to include it |
|---|---|---|
| iPhone with Safari | The iOS mobile browser path, including its browser and OS behavior. | Include it when iOS users are part of your audience. Choose a model and supported iOS version that reflect your users. |
| Android phone with Chrome | An important Android browser path and a different mobile platform. | Include it when Android users are part of your audience. Prefer a device representative of your actual visitors when practical; a flagship alone may not represent them. |
| iPad with Safari | Tablet-width layouts, navigation, and interactions. | Add it when tablet traffic is meaningful or the product has tablet-specific behavior. |
This is a baseline of categories, not a current global ranking of exact phone models. Check your own analytics before buying. Vendor device lists can help generate candidates, but their models and selection methods should be checked against your audience and the date you use them. BrowserStack’s device-selection reference describes factors such as traffic and popularity, operating systems, viewports, manufacturers, launch year, and country-specific additions.
3. Expand coverage by risk, not by device count
Add a device when it covers a meaningful difference in your users, product, or bug history. Compare candidates across these dimensions:
- Audience and geography: Prioritize devices your customers actually use, with country-specific patterns in mind.
- Browser and OS version: Test the browser family and supported software range, not just a screen-size profile.
- Viewport geometry: Cover materially different widths and heights, especially the narrowest supported layout and tablet widths.
- Hardware and manufacturer: Android hardware varies. Select devices with relevant traffic or known behavior rather than attempting exhaustive coverage.
- Form factor: Add tablets, foldables, or other forms when audience data or a feature justifies them.
- Test cost and frequency: Compare owning a small set with access to cloud devices. Verify current catalogues, real-device availability, supported browser versions, and pricing directly with any vendor.
Device profiles may expose pixel ratio, touch points, safe areas, or cutouts, but a profile remains an emulation. Bezel’s device catalogue is one example of a vendor reference for device-profile variables; treat it as a catalogue, not proof that emulation reproduces a physical device.
4. Use emulation for speed, real devices for confidence
Desktop browser device modes are useful for iterating on responsive layouts and breakpoints. They let you adjust viewport dimensions quickly and inspect layout changes without repeatedly switching hardware. They are not a complete substitute for mobile browsers: browser APIs, CSS support, and behavior can differ. Google’s guidance explicitly distinguishes responsive emulation from checking browsers on real devices. Chrome for Developers: Emulate and Test Other Browsers
- Iterate locally: Use desktop emulation across the important viewport widths. Check overflow, text wrapping, navigation, and responsive transitions.
- Verify platform-specific journeys: Use physical iPhone/Safari and Android/Chrome devices for high-value flows and browser-dependent behavior.
- Add tablets and accessibility paths: Test them when traffic, design, or accessibility needs call for them.
- Expand from evidence: Add coverage when analytics, customer reports, or a reproduced bug points to a missing device, browser, or form factor.
This sequence is a practical recommendation, not a universal test plan. The right coverage depends on your users and what your site does.
5. Include mobile accessibility when it is in scope
Responsive layout checks do not answer every accessibility question. Include assistive technology on the mobile platforms your users rely on, because interaction can differ between platforms. The Mobile Accessibility Testing Methodology describes testing on mobile and tablet devices, testing with assistive technology, checking responsive windows on desktop, and desktop testing. It recommends baseline iPhone/Safari, iPad/Safari, and Android phone/Chrome combinations. The methodology is from 2018, so use it for its testing approach rather than current OS-version details.
- Test key journeys with the platform’s assistive technology where feasible.
- Check focus order, labels, control activation, and dynamic updates on actual mobile interfaces.
- Include devices and technologies relevant to the people your site serves.
6. Capture repeatable visual evidence
For visual regression work, record the tested device category, browser, OS version, viewport, page state, and any relevant interaction. Keep the capture conditions consistent: the same URL, content state, viewport, and scroll position make comparisons more useful. A screenshot can document a rendered page, but it does not prove that touch interaction, browser APIs, or assistive technology behaves correctly. Keep functional checks on the relevant real devices.
For repeatable page captures across viewports, ScreenshotNeo is a website screenshot API and MCP server for developers. Its API can return PNG, JPEG, WebP, or PDF captures, and it supports full-page captures, device presets or custom viewports, and custom CSS or JavaScript. See the ScreenshotNeo website and API documentation.
7. Choose owned devices or cloud access
A small physical set is useful when you frequently verify the same important platform paths or investigate device-specific bugs. Cloud device testing may help teams that need broader combinations or do not have a device lab. Check the provider’s current device catalogue, real-device versus emulator availability, browser versions, automation support, and costs before choosing. The Chrome developer page names cloud testing services, but its vendor references date to 2015 and do not verify current features or terms.
Keep the distinction clear: a remote physical device can expose hardware and browser behavior that a desktop viewport profile cannot; an emulator or simulator has its own coverage and limitations. Use the option that matches the question you need to answer.
8. A repeatable mobile testing checklist
- Review analytics by country, OS, browser, and form factor.
- Choose an iPhone/Safari and Android/Chrome baseline if both platforms matter.
- Add an iPad when tablet use or tablet-specific behavior warrants it.
- Use desktop emulation to iterate through key responsive widths.
- Run critical flows on real mobile devices, including browser-dependent behavior.
- Include mobile assistive technology when accessibility is in scope.
- Record device, browser, OS, viewport, page state, and result for reproducibility.
- Expand coverage in response to usage data, support reports, and actual defects.
9. Troubleshooting coverage gaps
| Symptom | Likely cause | What to do |
|---|---|---|
| A page looks correct in desktop device mode but fails on a phone. | The issue depends on mobile browser APIs, CSS support, or device behavior that emulation does not reproduce. | Reproduce on the target browser on a real device. Record the OS and browser version, then add a regression check for that path. |
| Testing one iPhone or one Android phone misses customer bugs. | The selected device does not represent the relevant audience, software range, or hardware variation. | Check analytics and bug reports. Add a device or version only when it covers meaningful traffic or a known failure mode. |
| A responsive layout works at common widths but breaks on a tablet. | The matrix covers phone sizes but not the tablet breakpoint or tablet navigation behavior. | Add tablet viewport checks and, when tablet users or interactions matter, verify on an iPad. |
| A screenshot looks right, but a form or menu is unusable. | A visual capture cannot establish that touch input, keyboard behavior, or assistive technology works. | Run an interactive check on the relevant physical device and assistive technology. |
| A cloud device run does not match a locally observed issue. | The cloud session may use a different browser version, device type, or emulated environment. | Compare the exact device type, browser and OS versions, and whether the session used a physical device or emulator. Reproduce under matching conditions. |
10. ScreenshotNeo for repeatable page captures
ScreenshotNeo can capture a page with one GET request. The examples below use the same target URL and save the returned image bytes. The API and its options are documented at screenshotneo.com/docs.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpPython
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
r.raise_for_status()
with open("shot.webp", "wb") as f:
f.write(r.content)Node.js
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));For repeatable capture jobs, use the documented options for full-page capture, CSS selectors, dark mode, viewport and device presets, retina scale, custom CSS or JavaScript, click-before-capture, hidden elements, waits, request blocking, headers, cookies, user agent, timezone, geolocation, transparent backgrounds, resizing, caching, signed public image links, asynchronous jobs, bulk capture, and usage reporting. The service also provides PDF capture, HTML/CSS rendering, an OpenAPI specification, and familiar parameter names used by other screenshot APIs to ease switching. Use the docs for exact parameter names and combinations.
ScreenshotNeo removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture, and each cleanup step can be turned off. It reports page verdict and billing status in response headers; bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
For cost planning, the free plan includes 1,000 screenshots per month with no card. Paid plans are Starter at $5 for 3,000, Growth at $15 for 15,000, Pro at $39 for 60,000, Scale at $99 for 250,000, and Business at $249 for 1,000,000; yearly billing gives two months free. Every feature is available on every plan. These captures help with page evidence and visual checks; they do not replace interactive real-device testing.
Or skip the browser setup
Make a single request to capture a page; replace the URL with the page you need. See the ScreenshotNeo API docs for formats and options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp- Cookie banners, popups, and chat widgets are removed before the shot.
- Bot checks, blank pages, and failed loads are never billed.
- An MCP server lets AI agents take screenshots.
- 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000.
Create a free ScreenshotNeo account and capture up to 1,000 screenshots a month without a card.
Frequently asked questions
Which phones should I test my website on first?
Use an iPhone with Safari and an Android phone with Chrome when both platforms are relevant to your audience. Pick models and software versions using your analytics and support evidence.
Do I need to test every phone model?
No. Cover meaningful differences in audience, browser, viewport, hardware, and form factor, then expand when evidence identifies a gap.
Can desktop emulation replace testing on a phone?
It is useful for responsive iteration, but not for certainty about mobile browser and device behavior. Validate important browser-specific flows on real devices.
When should I include an iPad?
Include one when tablet traffic is meaningful or when tablet navigation, layout, or interaction differs from the phone experience.
Does a screenshot prove that a page works on mobile?
No. It records a rendered state. Use interactive checks for touch behavior, browser APIs, forms, and assistive technology.
Sources and evidence limits
- W3C, Guidelines for writing device independent tests (Working Group Note, 2009).
- Google Chrome for Developers, Emulate and Test Other Browsers (page last updated 2015).
- ICT Accessibility Testing Symposium, Mobile Accessibility Testing Methodology (2018).
- BrowserStack, Test On The Right Mobile Devices (vendor reference).
- Bezel, Responsive testing beyond the viewport (vendor catalogue).
The sources support a selection method and device categories, not a current universal ranking of exact phone models. Verify current device availability and vendor terms directly before purchasing or selecting a cloud service.
