How to Screenshot a Responsive Website at Desktop and Mobile Widths

To screenshot a responsive website at desktop and mobile widths, set the browser viewport to each width you want to document, then capture the visible viewport or the full page. For a one-off comparison, Chrome DevTools Device Mode is the quickest route. For repeatable screenshots, use Playwright and save each viewport under a descriptive filename.

For example, you might capture a page at 1440 × 900 and 390 × 844 CSS pixels. Those are example dimensions, not universal desktop and phone standards: choose dimensions from your brief or around the responsive breakpoints you need to inspect. A mobile-width emulation is useful for checking layout, but it does not prove how the page renders on a particular physical phone.

1. Choose what the screenshots need to show

Before capturing, decide on the viewport dimensions, page area, and output scale. These choices affect what the image means and whether two captures can be compared fairly.

Choice	Use it when	Keep in mind
Viewport screenshot	You need to show what fits on screen without scrolling.	It excludes content below the fold.
Full-page screenshot	You need to show the complete scrollable page.	It answers a different question from a viewport shot; label it clearly.
CSS-pixel scale	You want consistent layout-oriented comparisons.	Image output dimensions correspond to CSS sizing.
Device-pixel scale	You need higher-density output.	The image can have more pixels than the CSS viewport. Note the scale when comparing files.
Emulation	You need controlled, repeatable browser captures.	It simulates device-related browser settings; it is not a physical-device rendering check.
Actual hardware	The requirement calls for evidence from a real phone or tablet.	Use a physical device and, when debugging, Chrome’s remote debugging workflow.

Responsive layouts can change at CSS breakpoints, so set dimensions explicitly instead of relying on whatever viewport happens to be active. When repeatability matters, record the width, height, capture type, scale, and device preset or custom settings.

2. Capture desktop and mobile widths with Chrome DevTools

Open the target page in Chrome, then open DevTools.
Turn on Device Mode using the device toolbar control.
For the desktop capture, enter the requested width and height, or use the normal desktop viewport if that is the evidence you need.
Open the Device Mode menu and choose its screenshot option for a viewport capture. Choose Capture a full size screenshot when the complete page, including below-the-fold content, is required.
Change the viewport to the requested mobile dimensions, or choose a device preset, then capture again.
Save separate files with dimensions in their names, such as page-desktop-1440x900.png and page-mobile-390x844.png.

Chrome describes Device Mode as a set of features for simulating mobile devices. A preset can help approximate device-related browser settings, while a responsive custom viewport gives you precise dimensions. If a deliverable needs proof from an actual phone, use real-device debugging rather than presenting an emulated screenshot as hardware evidence.

3. Automate the captures with Playwright

Playwright is useful when you need to repeat the same desktop/mobile pair, attach images to a test run, or capture several pages. The following runnable Node.js example takes viewport screenshots at two custom sizes. It uses CSS-pixel output by default.

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  try {
    const page = await browser.newPage({
      viewport: { width: 1440, height: 900 },
      deviceScaleFactor: 1,
    });

    await page.goto('https://example.com', { waitUntil: 'networkidle' });
    await page.screenshot({ path: 'page-desktop-1440x900.png' });

    await page.setViewportSize({ width: 390, height: 844 });
    await page.screenshot({ path: 'page-mobile-390x844.png' });
  } finally {
    await browser.close();
  }
})();

Save the file as responsive-shots.js, install Playwright with npm install playwright, and run node responsive-shots.js. Playwright downloads browser binaries during setup if needed. Replace the example URL and dimensions with the page and sizes you need.

Capture the full page

Add fullPage: true to each screenshot call to include content below the fold:

await page.screenshot({
  path: 'page-desktop-full.png',
  fullPage: true,
});

Use this deliberately: a full-page image and a viewport image communicate different things. For pages with sticky elements or content that loads as you scroll, inspect the output to confirm the full-page capture represents the state you intended.

Use a device preset or higher pixel density

Playwright device presets can set properties such as viewport, screen size, user agent, and touch support. A preset represents a specific platform; for reproducible work, record the preset used. You can also set a custom viewport directly, as in the example. Set deviceScaleFactor to a value above 1 when you want device-pixel output; keep it at 1 for consistent CSS-oriented comparisons.

Emulation is not identical to testing on physical hardware. If the task requires actual-device evidence or behavior, use a real device. Chrome documents remote debugging as a way to view, change, debug, and profile a page running on an actual mobile device.

Wait for dynamic content before capturing

The example waits for network activity to become idle before the first screenshot. Some pages keep connections open or load content later, so no single wait condition works for every site. For a dynamic page, wait for the specific content you need, for example with await page.locator('main').waitFor();, or wait for a known selector or application state. If fonts or images are still changing, wait for them to finish before capturing. Use a deliberate timeout for pages whose loading behavior is unpredictable.

4. Name and compare the files consistently

Use filenames that say which page, viewport, and capture type they represent. For example:

pricing-desktop-1440x900-viewport.png
pricing-mobile-390x844-viewport.png
pricing-mobile-390x844-full-page.png

When you share or archive a comparison, include the URL, capture date, dimensions, browser or device preset, and pixel scale in a note. This helps someone reproduce the image and prevents an accidental comparison of different viewport areas or output scales.

5. Troubleshoot common capture problems

Symptom	Likely cause	Fix
Desktop and mobile images look identical.	The viewport did not change, or the page has no layout change at those widths.	Confirm the active width in DevTools or call `setViewportSize` before the second capture. Try dimensions around the site’s actual breakpoints.
The screenshot misses content below the fold.	A viewport screenshot captures only the visible area.	Use Chrome’s full-size screenshot option or Playwright’s `fullPage: true`.
Text, images, or layout shift between runs.	Fonts, images, animations, or client-rendered content were not ready.	Wait for the relevant selector and assets; disable or wait out animations if they make the comparison unstable.
Playwright hangs waiting for navigation.	The page keeps network requests active, so `networkidle` may not occur promptly.	Use a suitable navigation condition, then wait for a specific page element or state instead of relying on network idleness.
The mobile capture differs from the target phone.	Viewport emulation does not reproduce every hardware, browser, or operating-system detail.	Record the preset and settings, and use the actual device when the deliverable requires physical-device evidence.
Image dimensions are larger than expected.	Device-pixel scaling produces more output pixels than CSS-pixel scaling.	Use CSS scale or `deviceScaleFactor: 1` for layout comparisons, or document the higher scale.

6. Performance, reliability, and file size

For a pair of local captures, browser startup and page loading usually dominate the work. Reuse one browser and page when capturing multiple sizes, as the Playwright example does, rather than starting a new browser for every image. Use the shortest wait that reliably represents the content you need: waiting for every network request can be slow or unsuitable for pages with persistent connections.

Full-page and high-density screenshots contain more pixels and can take longer to produce and occupy more storage than viewport or CSS-scale captures. For visual comparisons, keep the same viewport, capture type, scale, browser settings, and content state across runs. A screenshot is a record of one page state; it does not establish that the site will behave identically on every device.

7. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request can return a PNG, JPEG, WebP, or PDF. Set a viewport width and height to capture responsive layouts. See the 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 \
  -d width=1440 -d height=900 \
  -o page-desktop.webp

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

For each capture, change the dimensions and output filename as needed. The same endpoint accepts the parameter names used by other screenshot APIs, which can make switching easier.

Cookie and consent banners are accepted like a visitor would accept them, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and whether the request was billed. An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

8. Frequently asked questions

Is 390 pixels the right width for every mobile screenshot?

No. It is an example width. Use the dimensions in your requirements or select widths that exercise the page’s responsive breakpoints.

Should I use a device preset or a custom viewport?

Use a custom viewport when exact width and height are the main requirements. Choose a preset when you also want its configured device properties, and record which preset you used.

Can an emulated screenshot prove how a page looks on a real phone?

It shows the page under emulated browser and viewport settings. For evidence from a specific physical phone, capture on that device.

Why do two screenshots at the same width still differ?

The page content or browser state may have changed, including loaded data, fonts, animations, or device settings. Keep the capture conditions and page state consistent, and note them alongside the files.