How to Test a Website on Mobile Screens

Test a website on mobile screens in layers: check its viewport setup, use browser emulation to explore widths and orientations, test accessibility and touch interactions, then verify important journeys on physical iOS and Android devices. Emulation is fast for finding layout bugs, but it cannot reproduce every hardware, browser, CPU, or operating-system behavior.

1. Choose a useful test matrix

There is no universal list of phone models that suits every site. Choose coverage from your audience analytics, supported browsers, and the importance of each user journey. Start with representative narrow and wide phone widths, the operating systems and browsers you support, portrait and landscape orientation, and at least one slower network condition.

Dimension	What to include	Why it matters
Viewport	A narrow phone, a typical phone, and a wider phone width	Find overflow, cramped controls, and breakpoint defects.
Platform	Current iOS and Android versions relevant to your users	Browsers, system UI, input, and rendering behavior can differ.
Browser	The browsers you support or see in analytics	Check browser-specific layout and interaction differences.
Orientation	Portrait and landscape for relevant screens	Rotation changes available space and can affect media or fixed elements.
Network	A normal connection and a constrained connection	Expose slow-loading content and interactions dependent on network timing.
Journey	Prioritize sign-in, search, forms, checkout, and other critical flows	A layout that looks right can still fail during real use.

Write down the matrix before testing. It keeps coverage intentional and helps you reproduce defects. Expand it when analytics, support reports, or the risk of a flow call for more combinations.

2. Check the viewport configuration

Confirm that the document head has a viewport meta tag whose content includes width=device-width. Without a suitable viewport declaration, some mobile browsers may use a wider virtual layout viewport and scale the page down, making a broken responsive layout appear merely small.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Example page</title>
</head>
<body>
  <main><h1>Example page</h1></main>
</body>
</html>

width=device-width makes the layout viewport follow the device width. The initial scale sets the initial zoom. Test your page at normal zoom and with text enlargement or zoom; do not rely on disabling user zoom to make a layout look correct.

Responsive design adapts layouts and other features to conditions such as screen size and resolution. Media queries, flexible grid or flex layouts, and responsive images are common implementation tools. See MDN’s responsive design guide.

3. Emulate mobile widths in Chrome DevTools

Open the page in Chrome and open DevTools.
Turn on Device Mode, then select Responsive dimensions.
Drag the viewport from narrow to wider phone widths. Inspect the intermediate widths too, not just familiar device presets.
Switch between portrait and landscape.
Exercise important controls while the viewport is emulated.

Look for horizontal scrolling, clipped controls, overlapping content, sudden breakpoint jumps, text that is too small to read, and fixed headers that cover headings or focused fields. Check dialogs, navigation menus, sticky bars, tables, long words, images, video, and embedded content.

Emulation is useful for quick iteration and repeatable viewport checks. It is not equivalent to a physical phone. Chrome’s guidance is explicit: “There are some aspects of mobile devices that DevTools will never be able to simulate.” When a defect is uncertain or a journey is important, test on a device; Chrome advises, “When in doubt, your best bet is to actually run your page on a mobile device.” See Chrome DevTools Device Mode.

4. Test interactions, content, and accessibility

Touch and forms

Tap through menus, links, buttons, carousels, date pickers, autocomplete fields, authentication, uploads, checkout, and error states. Confirm controls respond reliably to touch, are not hidden behind other elements, and have enough room to use without accidentally activating a neighbor. Check that forms use meaningful labels, show understandable validation errors, and avoid unnecessary typing where an appropriate input or autocomplete can help.

Keyboard, focus, and assistive technology

Use a keyboard where available and verify that focus is visible and follows a sensible order. Test meaningful labels and names, screen-reader announcements, and core flows with VoiceOver on Apple platforms and TalkBack on Android where available. Check that dialogs move focus appropriately and that users can dismiss them and return to the page.

Zoom, orientation, and contrast

Try text enlargement or zoom, rotate the device, and make sure essential content and controls remain available. Do not communicate status or meaning through color alone. MDN’s mobile accessibility checklist gives WCAG 2.2 AA contrast thresholds of 4.5:1 for normal text and 3:1 for large text. See MDN’s mobile accessibility checklist.

Images and other content

Check that images keep their proportions and that responsive image choices do not force unnecessarily large downloads on small screens. Ensure video, embeds, tables, and long words fit or have an intentional way to view their content without breaking the page layout.

5. Run a repeatable Lighthouse audit

Run a mobile Lighthouse audit for a repeatable signal. Review viewport and content-width findings, then investigate the underlying page and user experience. An audit can highlight issues, but it does not prove that every layout, touch, assistive-technology, network, or physical-device problem is absent.

Use audit results alongside manual checks: a passing report cannot establish that a checkout works with touch, that focus is visible, or that a fixed header does not obscure content at an unusual width.

6. Confirm critical journeys on real devices

For important mobile audiences, run critical flows on at least one current Android device and one current iPhone or iPad combination. Check the parts emulation cannot fully reproduce: touch behavior, sensors, browser chrome, CPU constraints, and operating-system differences. Include the actual journey, such as signing in or submitting a form, rather than looking only at the landing page.

A real-device cloud service can extend coverage across browsers and operating systems. BrowserStack documents access to Chrome DevTools and Safari Web Inspector during Android and iOS sessions. See BrowserStack Live documentation. Choose coverage based on the browsers and devices you need, and weigh fidelity, breadth, accessibility depth, network realism, cost, iteration speed, and defect reproducibility.

7. Capture defects so they can be fixed

For each issue, record the page URL, device or emulated viewport, operating system, browser and version, orientation, network condition, reproduction steps, expected result, actual result, and a screenshot or recording. Include whether the issue occurs in emulation, on physical hardware, or both. This gives another developer enough context to reproduce the failure.

8. Troubleshooting common mobile test failures

Symptom	Likely cause	What to check or fix
The whole page looks like a shrunken desktop site	Missing or incorrect viewport metadata	Check the head for a viewport declaration with `width=device-width`, then inspect the responsive layout.
Horizontal scrolling appears at one width	A fixed-width element, long word, table, image, or embed exceeds the viewport	Inspect the overflowing element at the failing width; make it responsive or give wide data an intentional scrolling treatment.
Controls overlap after rotation	Layout assumptions break when height and width change	Re-test the rotated viewport, dialogs, fixed bars, and available scrolling area.
A menu or button works in desktop testing but fails on a phone	Touch behavior, overlays, or a mobile-specific interaction differs	Tap the control on physical hardware, check hit areas and stacking, and test the full interaction.
A heading or input disappears under a sticky header	Fixed positioning obscures content when scrolling or focusing	Scroll and focus fields on a phone; adjust the layout so the target remains visible.
The page passes emulation but fails on a device	Emulation does not reproduce all hardware, browser, CPU, sensor, or OS behavior	Capture device, OS, browser, orientation, and steps; use physical or cloud-device testing for the affected combination.
A Lighthouse pass gives false confidence	An audit is a signal, not a complete interactive or device test	Manually run keyboard, screen-reader, touch, zoom, orientation, and critical-flow checks.
A defect is hard for a teammate to reproduce	Viewport, browser, network, or exact steps were omitted	Record the full reproduction details and attach a screenshot or recording.

9. Performance, reliability, and cost

Browser emulation is quick for repeated layout changes and costs little beyond development time. Physical devices add realistic interaction and platform checks but require access to the relevant hardware. Real-device cloud services can broaden coverage; account for service costs and session time when choosing how many combinations to run.

For reliable results, keep a small, stable set of critical journeys and rerun them after layout or interaction changes. Use emulated widths for fast feedback, and reserve hardware or cloud-device runs for high-risk journeys and platform-specific behavior. A screenshot is useful evidence of visual state, but it cannot establish that touch, screen-reader, keyboard, form submission, or network-dependent behavior works.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. It can capture a page as PNG, JPEG, WebP, or PDF, and its parameters include viewport and device presets, full-page capture, waits, custom CSS and JavaScript, and request options. A screenshot is useful for documenting visual states during responsive review; it does not replace testing interactions or physical-device behavior.

See the ScreenshotNeo API documentation for the request options. This cURL example saves a screenshot of a test page:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Equivalent runnable examples in Python and Node.js:

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()
open("shot.webp", "wb").write(r.content)

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 fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

Cookie banners are accepted and removed before capture, along with 60+ known consent platforms, newsletter popups, and chat widgets; each step can be turned off.
Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers report the page verdict and billing status.
An MCP server lets AI agents using Claude, Cursor, or another MCP client take screenshots, inspect page info, and capture PDFs.
The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots; every feature is available on every plan.

FAQ

Is Chrome mobile emulation enough?

It is a good first pass for layout and viewport defects. Verify critical interactions on physical devices because emulation cannot reproduce every mobile behavior.

Do I need to test every phone model?

No universal model list applies. Use analytics, supported platforms, and flow risk to select representative coverage, then expand when evidence calls for it.

Should I test portrait and landscape?

Yes, when users may rotate the device or when a screen’s available space affects its content or controls.

Can a screenshot prove that a page works on mobile?

No. It can show a rendered visual state, but interaction, accessibility, and hardware behavior require their own checks.