How to Emulate Mobile Browsers for Website Testing

To emulate mobile browsers for website testing, start with your desktop browser’s responsive or device mode to check layouts at different viewport sizes. Use an operating-system simulator when you need to investigate platform behavior, and verify important mobile-browser or hardware-dependent issues on a real device. Desktop emulation is a useful approximation; it does not turn a desktop computer into the target phone.

Chrome’s documentation calls Device Mode a first-order approximation and advises: “When in doubt, your best bet is to actually run your page on a mobile device.” Google Chrome for Developers’ Device Mode guide explains its controls and limitations.

1. Choose the right level of fidelity

Match the test environment to the question you need to answer. A layout defect usually needs a viewport preview. A problem involving an on-screen keyboard, mobile API, browser behavior, or hardware calls for a simulator or physical device.

Method	What it is useful for	What it cannot establish alone
Desktop browser responsive mode	Quick checks of viewport sizes, breakpoints, orientation, and some network or CPU conditions.	Exact mobile hardware, operating-system integration, or every mobile browser difference.
Platform simulator or emulator	Investigating behavior in a more representative operating-system environment and automating platform-specific checks.	All hardware behavior or every real-device condition.
Physical device	Verifying the actual target browser and OS, hardware-dependent interactions, and defects that remain uncertain in emulation.	Other devices, OS versions, browsers, or customer configurations.
Cloud browser/device service	Adding automated coverage across environments when the team needs broader test scale.	Any combination not included in the service’s available environments.

Browser emulators do not reproduce every mobile API, CSS support difference, or browser behavior. See Chrome’s browser-emulation guidance for the distinction between emulating a browser and emulating a device.

2. Check responsive layouts in desktop browser tools

Chrome DevTools

Open the page in Chrome and open DevTools.
Toggle Device Mode using the device toolbar button or the DevTools command menu.
Choose a device profile or enter a custom viewport width and height.
Check the page at your design’s breakpoints and at widths between them. A named phone preset is only one sample.
Rotate the viewport and inspect layouts affected by orientation.
When investigating a slow connection or constrained device scenario, apply the available network or CPU throttling and repeat the interaction.
If relevant, test geolocation and other available device conditions.

Device Mode supports viewport simulation, device profiles, orientation, CPU and network throttling, and geolocation controls. The exact controls depend on the DevTools version. These conditions help reproduce selected scenarios; they do not reproduce the target phone’s full browser and hardware stack. See Simulate mobile devices with Device Mode.

Firefox Responsive Design Mode

Open Responsive Design Mode from Firefox’s developer tools.
Select a listed device size or enter a custom viewport.
Inspect the page at the breakpoints relevant to your design and between them.
Use the available network-condition controls when testing the effect of slower connections.

Firefox can set the content viewport to a device or custom size and approximate network characteristics. These settings are useful for responsive checks; they do not make desktop Firefox equivalent to a particular phone. Refer to Mozilla’s Responsive Design Mode documentation.

Safari Responsive Design Mode

Open the page in Safari on a Mac and enable the Develop menu if needed.
Choose Enter Responsive Design Mode from the Develop menu.
Select a viewport or resize the preview to examine media queries and dynamic styles.
For a more representative Apple-platform preview, use the available Open with Simulator workflow where appropriate.

Responsive Design Mode is useful for layout previews, but the address bar, onscreen keyboard, and device-specific form behavior can affect the actual layout. See Apple’s Responsive Design Mode documentation.

3. Decide when to move beyond desktop emulation

Move to a simulator or real device when the bug depends on an operating-system interaction, mobile browser API, platform-specific rendering, or hardware behavior. Examples include a layout changing when the mobile keyboard opens, a permission prompt, touch input, or an issue that appears only in a specific mobile browser.

For Apple platforms, use Responsive Design Mode for a quick layout preview, then use Simulator or a connected iPhone or iPad when the defect calls for greater platform fidelity. Safari can inspect pages on connected devices and simulators, including the device and OS version. Follow Apple’s instructions for inspecting apps and devices.

For a real-device check, reproduce the affected interaction in the target browser and record the device model, OS version, browser version, viewport or orientation, and relevant network conditions. That record makes the result easier to reproduce; it does not imply that one phone represents every user’s configuration.

4. Automate repeatable mobile-emulation checks

ChromeDriver: emulated Chrome configuration

ChromeDriver can start Chrome with a known mobile device profile or explicit device attributes. The following Python example is runnable with Selenium and ChromeDriver installed and available to Selenium. It opens a page with a mobile emulation configuration and prints the resulting title.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_experimental_option("mobileEmulation", {"deviceName": "Pixel 7"})

driver = webdriver.Chrome(options=options)
try:
    driver.get("https://example.com")
    print(driver.title)
finally:
    driver.quit()

Replace Pixel 7 with a device name supported by your ChromeDriver version, or configure the supported mobile-emulation attributes described in the ChromeDriver mobile emulation documentation. Profile availability can depend on the Chrome version. ChromeDriver emulation is useful for repeatable checks, but Chrome explicitly cautions that it is not a perfect replication of a real device.

Safari WebDriver

Apple documents Safari WebDriver automation, including automation for iOS and iPadOS through a connected Mac. Enable the required Safari automation settings and follow Apple’s setup and platform instructions in its WebDriver documentation. Choose the browser and OS combinations that matter to your product. Automated runs still need a fidelity-aware test plan: a scripted result in one environment does not establish real-device behavior everywhere.

cURL, Python, and Node.js for screenshot capture

These examples request a rendered screenshot through ScreenshotNeo’s API. They are useful when a repeatable image of a URL is enough for a visual check; a screenshot alone cannot exercise a mobile keyboard, touch sequence, or other interactive behavior. See the ScreenshotNeo API documentation for request options.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.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://example.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));

Use a secret key from your account; do not expose it in a public webpage or client-side bundle. For JavaScript in a browser, proxy authenticated requests through a server you control.

5. Build a practical mobile test matrix

Start with the environments that correspond to your users and the risks in the feature under test. There is no universal number of phone models that guarantees coverage. A useful sequence is:

Test the responsive breakpoints and intermediate widths in desktop tools.
Run repeatable automated checks for the browser configurations your team supports.
Use the relevant platform simulator for OS-specific behavior.
Validate high-impact or hardware-dependent flows on physical devices using the actual target browsers.

For each issue or run, capture the page URL, device or emulation profile, viewport and orientation, browser and OS versions, network conditions, steps to reproduce, and expected versus actual result. This keeps comparisons meaningful when environments differ.

6. Performance, reliability, and cost

Keep quick checks cheap in time: use desktop responsive mode while iterating on CSS, then spend simulator and physical-device time on questions those tools can answer.
Test the slow path deliberately: throttling can reveal loading and layout problems that a fast desktop connection hides, but it is a selected condition rather than a complete network simulation.
Automate stable checks: use browser automation for repeatable layout or navigation assertions. Keep environment details with failures so a change in browser or profile does not look like an unexplained product regression.
Plan device coverage from risk: real devices provide the actual hardware/browser combination being tested, while one device cannot represent every audience configuration. Prioritize flows where a defect would matter most.
Use cloud services when scale warrants it: cloud-based emulators can broaden automated coverage. Service catalogs, prices, and capabilities vary; check current provider documentation before budgeting.
Screenshot cost: ScreenshotNeo has a free plan with 1,000 shots per month and no card, then paid plans starting at $5 for 3,000 shots. Its API bills only clean shots; bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with verdict and billing response headers. A screenshot API complements browser testing; it does not replace interactive device checks.

7. Troubleshooting mobile-emulation tests

Symptom	Likely cause	What to try
The page looks right in Device Mode but breaks on a phone.	Desktop emulation approximates a mobile browser and device; it does not reproduce all mobile APIs, hardware, or browser behavior.	Reproduce on the target browser and OS in a simulator or real device. Record versions and conditions.
A layout works at a preset width but fails on another phone.	The preset did not cover an intermediate width, different viewport, or browser UI effect.	Test custom widths around your breakpoints. Check Safari behavior involving the address bar, keyboard, or device-specific forms where relevant.
ChromeDriver rejects the device profile.	The named profile may not be present in that ChromeDriver version or the configuration may be invalid.	Use a supported profile for the installed version or configure the documented emulation attributes; keep Chrome and ChromeDriver compatible.
The automated run passes, but touch or keyboard behavior fails.	The test only exercised the emulated browser configuration or did not reproduce the OS interaction.	Test the interaction in the relevant simulator and on a physical device when it depends on actual hardware or mobile-browser behavior.
Safari automation does not reach an iPhone or iPad.	Apple’s mobile Safari WebDriver workflow requires its documented setup and a connected Mac.	Follow Apple’s current WebDriver setup for the target OS and enable the required automation settings.
Network throttling does not reproduce a user report.	The selected throttling profile may not match the user’s actual connection or the failure may have another cause.	Record the conditions, try a range of relevant network settings, and confirm on the target device if the issue remains uncertain.
A screenshot request returns an error or an unexpected page.	The target may require authentication, block automated access, fail to load, or render differently from the intended test session.	Check the response status and ScreenshotNeo’s `X-Page-Verdict` and `X-Billed` headers; configure supported request inputs in the API docs. Use a real browser session for interactive or authenticated behavior that a URL capture cannot establish.

8. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. For a quick rendered-page image:

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

See the ScreenshotNeo documentation for the API options. Cookie banners are accepted like a visitor would accept them, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are never billed. Response headers report the page verdict and billing result. An MCP server gives AI agents such as Claude, Cursor, and other MCP clients the tools take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.

FAQ

Does mobile emulation prove a page works on every phone?

No. It checks selected viewport and browser conditions. Verify behavior on the relevant OS, browser, and hardware when those differences matter.

Should I test every popular phone size?

Test the breakpoints your design uses and the widths around them, then prioritize target environments based on your audience and feature risks. A list of presets alone can miss failures between sizes.

Can a screenshot show whether a mobile interaction works?

A screenshot shows a rendered state. It does not prove that touch, keyboard, permission, or other interactive behavior works on a phone.

When should I use cloud testing?

Consider it when you need automated coverage across more environments than your local simulators and devices can reasonably cover. Confirm that the service supports the browser and OS combinations you need.