How to Capture Mobile Screenshots of a Web App at Different Breakpoints

To capture a web app at different mobile breakpoints, set the browser viewport to each width you want to inspect, then save a viewport or full-page screenshot. For quick manual checks, use Chrome DevTools Device Mode: enter the viewport dimensions, optionally show media-query bars to find CSS transitions, then capture. For repeatable captures across many widths, use Playwright with an explicit viewport for each screenshot.

Choose widths from your app’s CSS media queries or design requirements. There is no universal list of breakpoints that fits every app. Emulated mobile screenshots are useful for responsive layout checks, but they do not reproduce every behavior of a real phone.

1. Choose the widths and capture scope

Before capturing, decide which layout states you need to compare and whether each image should show the current viewport or the entire page.

Pick meaningful widths: inspect the widths around your app’s media-query transitions, plus any required design or QA viewport sizes. Include widths just below and above a transition to catch abrupt layout changes.
Choose a height: use a consistent viewport height when comparing what appears above the fold. For full-page captures, page height determines the scrollable content included.
Choose the scope: a viewport capture shows only what is currently visible; a full-page capture includes the scrollable page. Use the same scope in every comparison.
Keep conditions steady: use the same browser version, page state, content, and capture settings. Rendering can vary with the host operating system, browser version, settings, hardware, and other conditions.

For a responsive transition at width W, a useful check is W - 1, W, and W + 1 CSS pixels. This is a practical way to inspect either side of a transition; the actual widths should come from your app’s CSS or requirements.

2. Capture breakpoints manually in Chrome DevTools

Chrome DevTools Device Mode lets you change the emulated viewport interactively and capture the result. Chrome describes it as a way to approximate how a page looks and performs on a mobile device.

Open the web app in Chrome and open DevTools.
Enable the device toolbar. In the toolbar’s device selector, choose Responsive or responsive dimensions.
Enter the width and height you want to inspect, or drag the viewport handles. Record the dimensions if you need to repeat the capture later.
To locate CSS media-query transitions, open the device toolbar’s More options menu and enable Show media queries.
Inspect the displayed breakpoint bars. Click between bars to change the viewport width and trigger the corresponding breakpoint. Use your app’s CSS or design requirements to decide which transitions matter.
Open the capture menu and choose a screenshot of the visible viewport or a full-size screenshot of the page.
Repeat for each target width, keeping the page state and capture scope consistent.

Chrome’s breakpoint display helps you inspect transitions already defined by the page. It does not provide a universal breakpoint list for your design.

3. Automate repeatable captures with Playwright

For a set of known widths, automation makes the capture sequence repeatable. This Node.js example opens a page at each viewport size and saves both viewport and full-page screenshots. It uses explicit viewport dimensions so each run follows the same configuration.

import { chromium } from 'playwright';

const url = 'https://example.com';
const viewports = [
  { name: 'narrow', width: 320, height: 800 },
  { name: 'small', width: 375, height: 812 },
  { name: 'medium', width: 414, height: 896 },
  { name: 'wide', width: 768, height: 1024 },
];

const browser = await chromium.launch();
try {
  for (const viewport of viewports) {
    const page = await browser.newPage({ viewportSize: {
      width: viewport.width,
      height: viewport.height,
    }});
    await page.goto(url, { waitUntil: 'networkidle' });
    await page.screenshot({ path: `shot-${viewport.name}.png` });
    await page.screenshot({
      path: `full-${viewport.name}.png`,
      fullPage: true,
    });
    await page.close();
  }
} finally {
  await browser.close();
}

Save this as an ES module file in a project with Playwright installed, replace https://example.com with your page, and run it with Node.js. The viewport values above are example inputs, not a recommendation that every app should use those breakpoints.

To emulate a named device, configure a browser context with a Playwright device preset. Device settings can include screen size, user agent, and touch behavior. For a breakpoint audit, explicit viewport sizes make it clear which width is being checked; use a preset when you specifically need its bundled device configuration.

Playwright’s screenshot options let you choose among a viewport screenshot, an element screenshot, and a full-page screenshot. Device scaling controls whether output is based on CSS pixels or device pixels; device-pixel output may produce a larger image. Select the scale intentionally when comparing files or storing captures.

For authenticated or stateful pages, create the page with the required context settings and establish the intended page state before taking the screenshot. If the content depends on animations, delayed data, or lazy loading, wait for the relevant state or selector before capture. Use the same wait condition on each run so differences reflect the viewport rather than timing.

4. Check the result and keep comparisons useful

Label files with the viewport width and height, and note whether the image is viewport-only or full-page.
Compare adjacent widths around each transition to find wrapping, overflow, clipped controls, or unexpected layout jumps.
When a full-page image differs, check whether content height or lazy-loaded sections changed, not only the first screen.
For visual regression work, keep the browser version and host environment consistent. Rendering can vary across operating systems, browser versions, settings, and hardware.
If a defect may depend on actual touch input, mobile browser behavior, or device hardware, verify on a real phone. Device Mode is an approximation; Chrome’s documentation points to remote debugging for inspecting a page running on a mobile device.

5. Troubleshoot common capture problems

Symptom	Likely cause	What to do
The layout did not change at the expected width	The selected width does not cross the app’s media-query threshold, or the relevant rule differs from the assumed breakpoint.	Show media queries in Device Mode and inspect the app’s CSS or design requirements. Capture just below and above the actual transition.
The screenshot is too narrow or wide	The viewport dimensions were not set as intended, or a device preset supplied different dimensions.	Use Responsive mode with explicit width and height, or inspect the preset’s configured viewport before capture.
The image cuts off content	A viewport capture was taken when a full-page image was needed.	Use Chrome’s full-size screenshot option or Playwright’s `fullPage: true`.
The full-page image omits content loaded while scrolling	Some page content is lazy-loaded and was not ready when the capture occurred.	Wait for the page’s content to load or use a capture flow that scrolls through the page before taking the full-page shot. Check the resulting image for missing sections.
Repeated screenshots differ unexpectedly	Timing, page state, browser version, operating system, settings, or hardware may differ.	Use a consistent environment and wait condition. Keep content and capture settings steady before comparing.
The emulated layout looks right, but a real phone behaves differently	Device Mode does not run the app on an actual phone and cannot simulate every mobile characteristic.	Reproduce the issue on a real device and use remote debugging when you need to inspect the running page.
Playwright exits before all images are saved	A navigation or screenshot operation failed, or the browser was not closed reliably.	Inspect the first thrown error, make sure the URL is reachable in the browser context, and keep browser cleanup in a `finally` block.

6. Performance, reliability, and cost

Manual DevTools capture has little setup and is convenient for exploring widths, but each size requires an interactive capture. Playwright requires browser setup and a script, then can repeat a known list of sizes. A full-page capture or a page with delayed content can take longer and produce a larger file than a viewport capture. Device-pixel output may also increase image dimensions and file size.

For reliable comparisons, use the same browser version, host environment, viewport, page state, wait condition, and screenshot scope. Emulation is useful for layout checks, but it cannot establish that a page behaves identically on every phone. Confirm hardware-dependent issues on a real device.

Chrome DevTools and Playwright are software workflows; this process does not require buying a physical capture device. Browser automation does require time to install and maintain the browser runtime and script. If you need hosted captures without configuring a browser locally, use the API option below.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Send one GET request with a URL to receive an image or PDF. Its capture options include viewport dimensions and device presets, so you can request shots at the widths your responsive checks need. See the ScreenshotNeo API documentation for the request parameters and configuration.

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

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

Cookie banners are accepted and removed before the shot, along with known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers report the page verdict and billing status. An MCP server lets AI agents use screenshot tools. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Every feature is available on every plan.

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

FAQ

Does Chrome DevTools show my app’s breakpoints?

Yes. Enable Show media queries in Device Mode to display breakpoint bars for the page’s CSS media queries. Use the bars to move between widths around those transitions.

Should I use a device preset or enter dimensions?

Enter explicit dimensions when the goal is to check known responsive widths. Use a device preset when you need the preset’s associated device settings, such as screen size, user agent, and touch behavior.

Can a mobile screenshot prove the page works on a phone?

No. Emulation approximates mobile conditions. Use a real phone when the behavior depends on mobile hardware or characteristics that the browser cannot simulate.

When should I capture the full page?

Use a full-page image when the review needs to include content below the fold. Use a viewport capture when you are checking what fits in the visible screen at a particular width and height.