How to Choose a Device Viewport for Website Screenshots

The right screenshot viewport is the one that exercises the responsive behavior you need to inspect. Start with the website’s actual CSS media-query breakpoints, capture widths just below and above important transitions, and keep the viewport dimensions and screenshot scale fixed when comparing images. A named phone or laptop preset is only a convenient example; it is not a universal standard.

This guide explains how to choose dimensions, distinguish CSS pixels from device pixels, decide between viewport and full-page captures, emulate device behavior, automate the process with Playwright, and use ScreenshotNeo when you do not want to maintain a browser setup.

1. Start with the question your screenshot must answer

Write down the review question before choosing a width. Different questions need different capture settings:

Goal	Viewport choice	Capture choice
Find a responsive layout bug	Widths immediately below, at, and above the relevant CSS breakpoints	Viewport-only first; full-page when lower sections are affected
Review the first screen	The width and height of the target context	Viewport-only
Approve a design handoff	Fixed, documented dimensions that show the intended composition	Viewport or full page, recorded with the review
Create a visual-regression baseline	A small, stable matrix of widths that cover your breakpoints	The same mode and scale on every run
Represent a particular device	Its CSS viewport dimensions	Add device scale factor, user agent and mobile behavior when required

Record width, height, scale mode, page URL, browser version, and whether the image is viewport-only or full-page. Without those values, two screenshots that look like the same device may not be comparable.

2. Find the site’s real breakpoints

Breakpoints are conditions in the site’s CSS, such as @media (min-width: 768px). They are more useful than a generic “tablet” label because they identify where this site changes navigation, grids, typography, or spacing.

1. Open the page in Chrome DevTools and switch to Device Mode.
2. Inspect the stylesheet or the Computed panel for min-width and max-width media queries.
3. Note every breakpoint that changes the component under review.
4. Capture one or two pixels below the breakpoint, exactly at it, and one or two pixels above it. A transition can expose an off-by-one rule or an element that wraps unexpectedly.

Chrome Device Mode displays breakpoint markers and lets you move the responsive viewport between them. Its named presets are useful starting points, but they are examples rather than required test sizes. The current guide lists Mobile S 320px, Mobile M 375px, Mobile L 425px, Tablet 768px, Laptop 1024px, Laptop L 1440px, and 4K 2560px. See Chrome’s Device Mode documentation.

A practical breakpoint matrix

Suppose a menu changes at 768px and a three-column grid begins at 1024px. A compact matrix could be 767, 768, 769, 1023, 1024, and 1025px. Add a representative narrow width such as 320px and a wide width such as 1440px if those layouts matter. Do not test every integer width; test the transitions and the widths your users or design system explicitly supports.

3. Understand CSS pixels, device pixels, and DPR

Viewport dimensions are layout coordinates. A 375px-wide viewport tells the browser to lay out the page in 375 CSS pixels. The saved image can have the same number of pixels or more, depending on screenshot scale.

• CSS scale: one output pixel per CSS pixel. A 375px viewport produces a 375px-wide image.
• Device scale: output uses device pixels. With a device pixel ratio (DPR) of 2, the same 375 CSS pixels can produce an image about 750px wide.

Chrome describes DPR as how many screen pixels it uses to draw a CSS pixel. Playwright’s screenshot API exposes scale: 'css' and scale: 'device'; consult the Page API. Use CSS scale for stable pixel dimensions in visual diffs. Use device scale when you need a higher-resolution asset or want to represent a high-density display. A 375px viewport is therefore not automatically a 375px image.

4. Choose viewport-only or full-page capture

A viewport screenshot answers “what is visible in this window?” A full-page screenshot answers “what does the entire scrollable document look like?” Use viewport-only for hero sections, above-the-fold reviews, and responsive navigation. Use full-page for page archives, long-form design review, and visual regression of content below the fold.

Full-page capture can trigger lazy loading, sticky-header behavior, and very tall output files. If the page has animations, freeze them or wait for a stable state before capture. Playwright documents the fullPage option and screenshot behavior in its Page API.

5. Viewport resizing versus device emulation

Changing width and height tests responsive layout. Device emulation can additionally set device scale factor, user agent, mobile behavior, touch support, timezone, and geolocation. Configure those fields when the page has device-specific code, not merely because a preset has a familiar name.

Emulation is still a browser approximation. It does not prove that a physical phone has identical font rendering, GPU behavior, keyboard behavior, or network performance. For layout debugging, fixed viewport dimensions are usually the clearest signal. For device-specific behavior, combine dimensions with the relevant emulation fields. See Playwright’s emulation guide.

6. Automate repeatable captures with Playwright

Playwright creates a browser context with a fixed viewport, waits for the page to settle, and saves a screenshot. The example below tests widths around a breakpoint and saves CSS-scale PNGs.

import { chromium } from 'playwright';

const widths = [767, 768, 769, 1023, 1024, 1025];
const browser = await chromium.launch();

for (const width of widths) {
  const page = await browser.newPage({
    viewport: { width, height: 900 },
    deviceScaleFactor: 1
  });
  await page.goto('https://example.com', { waitUntil: 'networkidle' });
  await page.screenshot({
    path: `shot-${width}.png`,
    fullPage: false,
    scale: 'css',
    animations: 'disabled'
  });
  await page.close();
}

await browser.close();

Install with npm install -D playwright and run the file in a project configured for ES modules. Replace the URL and the width list with your page’s breakpoints. Playwright documents a default 1280 × 720 viewport for its consistent browser context, but set explicit values so a tool default never becomes an accidental baseline; see the Browser API.

Full-page and device-scale variants

const context = await browser.newContext({
  viewport: { width: 375, height: 812 },
  deviceScaleFactor: 2,
  isMobile: true,
  hasTouch: true
});
const page = await context.newPage();
await page.goto('https://example.com', { waitUntil: 'networkidle' });
await page.screenshot({
  path: 'mobile-full-page.png',
  fullPage: true,
  scale: 'device',
  animations: 'disabled'
});

Only add mobile emulation settings when your test needs them. Keep the same settings for every comparison in a series.

7. A checklist for reliable viewport screenshots

• Identify the CSS breakpoint or layout transition under review.
• Capture just below, at, and just above that width.
• Set an explicit height; do not depend on the host window.
• Choose CSS scale for stable diff dimensions or device scale for high-density output.
• Choose viewport-only or full-page based on the review question.
• Wait for fonts, images, and key selectors before capture.
• Disable animations and hide transient overlays when they are not part of the design.
• Keep browser, viewport, DPR, URL state, cookies, and authentication consistent.
• Store the settings beside the baseline image.

8. Troubleshooting viewport captures

Symptom	Likely cause	Fix
Image width is twice the viewport	Device scale or DPR is 2	Use CSS scale or divide expected dimensions by the device scale factor.
Layout changes at an unexpected width	A hidden media query, container query, or scrollbar changed available space	Inspect computed styles and test a few pixels on both sides; account for scrollbar width.
Mobile menu never appears	Width changed but mobile user-agent or touch behavior is required	Configure device emulation fields and verify the page’s feature detection.
Bottom sections are blank	Lazy loading has not fired	Scroll through the page, wait for images, or use a capture service that loads lazy images for full-page shots.
Headers or chat widgets cover content	Transient overlays loaded after navigation	Wait for a selector, hide the overlay, or remove it before capture.
Two runs differ without a code change	Animation, time, random data, ads, or fonts are nondeterministic	Freeze animations, mock volatile data, wait for fonts, and use stable authentication and cookies.
Full-page image is too large	Very long document or device-scale output	Use CSS scale, split the page, or capture only the relevant element.

9. Performance, reliability, and cost considerations

More widths multiply browser startup, navigation, rendering, and storage work. Reuse a browser process, create contexts per configuration, and avoid testing redundant widths. Wait for a meaningful readiness condition rather than an arbitrary long delay. For full-page captures, expect more image decoding and scrolling than for viewport-only captures.

Network idle is useful but not universal: analytics or long polling can prevent it. A selector that proves the page is ready is often more reliable. Cache static assets where your test environment permits, but keep cache behavior consistent between baseline and comparison runs. When a screenshot is part of a build, retry navigation failures separately from assertion failures and record the final viewport settings with the artifact.

10. Or skip the browser setup

ScreenshotNeo provides a website screenshot API and MCP server. You send one GET request with a URL and receive PNG, JPEG, WebP, or PDF. It supports explicit viewport values, 12 device presets and custom viewports, retina scale, full-page capture with lazy images loaded, element capture by CSS selector, dark mode, custom CSS and JavaScript, waits, request blocking, headers, cookies, user agents, timezone, geolocation, transparent backgrounds, resizing, caching, signed links, async jobs, bulk capture, and PDF options. Read the parameter details in the ScreenshotNeo documentation.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={
        "access_key": "YOUR_API_KEY",
        "url": "https://stripe.com",
        "viewport_width": 375,
        "viewport_height": 812,
        "scale": "css"
    },
    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',
  viewport_width: '375',
  viewport_height: '812',
  scale: 'css'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', data));

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed; response headers identify the page verdict and whether it was billed. An MCP server lets Claude, Cursor, and other MCP clients call take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account and start with the 1,000 monthly screenshots.

11. FAQ

What viewport should I use for a 375px phone screenshot?

Use 375 CSS pixels when that width matches your target or a breakpoint test. Decide separately whether the output should use CSS scale or device scale; the image may be wider than 375 pixels at high DPR.

Are Chrome’s preset widths web standards?

No. They are convenient examples supplied by Device Mode. Your site’s media queries and review goals determine the widths that matter.

Should every screenshot be full page?

No. Use viewport-only for the visible window and full-page when content below the fold is part of the question.

Does a responsive screenshot prove the site works on a real phone?

No. Browser emulation approximates device settings. Physical-device validation can reveal rendering, input, performance, and browser differences that a screenshot cannot establish.

How many widths belong in a visual regression suite?

Use the smallest set that covers every important layout transition, plus representative narrow and wide widths. Add widths when a bug or design requirement justifies them.