How to Capture a Webpage Screenshot at Mobile and Desktop Breakpoints for Documentation
Capture clear, repeatable mobile and desktop screenshots for documentation. Set exact viewport sizes, find real breakpoints, and label each image with its capture mode.
To document a page at mobile and desktop breakpoints, capture it at explicit viewport widths and heights, record those dimensions, and state whether each image shows only the visible viewport or the full scrollable page. Use Chrome DevTools for a one-off capture; use Playwright when you need to regenerate the same screenshots reliably. For a responsive transition, inspect the page’s actual media-query breakpoints instead of assuming a device preset is the breakpoint.
A useful pair might be a 375 × 812 CSS-pixel mobile viewport and a 1440 × 900 desktop viewport, but choose sizes that match the page and the documentation question. Chrome’s presets include 320, 375, 425, 768, 1024, 1440, and 2560 pixels wide; these are convenient starting points, not universal breakpoints. Chrome DevTools device mode documentation explains how to set dimensions, show breakpoints, and capture screenshots.
1. Decide what each screenshot should prove
Before capturing, decide whether the documentation needs to show the layout that fits on screen or the entire page at a particular width.
| Capture mode | What it shows | Use it to document |
|---|---|---|
| Viewport | The visible area at the selected width and height | Navigation, hero layout, above-the-fold content, or what a reader initially sees |
| Full page | The whole scrollable document, represented as a tall image | Page structure, long forms, article sections, or content order |
These modes answer different questions. Mark the mode in the filename or caption; a tall full-page image should not be presented as though it were a screen-sized viewport. For a side-by-side layout comparison, keep the height the same where practical. Change it when the documentation is specifically about a device-shaped viewport or the amount of content visible vertically.
2. Capture a breakpoint manually with Chrome DevTools
- Open the page in Chrome and open DevTools.
- Turn on the device toolbar. The toolbar opens in Responsive mode by default.
- Enter the exact viewport width and height. These dimensions are CSS pixels.
- To inspect the page’s responsive rules, open the device toolbar’s More options menu and enable Show media queries. Chrome shows max-width and min-width breakpoint bars. Click a breakpoint to set a width that triggers it; right-click between breakpoints and choose Reveal in source code to locate the corresponding rule.
- Wait for the page to settle, then open More options and choose Capture screenshot for the visible viewport. Choose Capture a full size screenshot for the complete scrollable page.
- Save each image with its viewport dimensions and capture mode in the name.
Example names: page-mobile-375x812-viewport.png and page-desktop-1440x900-full-page.png. Include the target URL, browser, and whether you used device emulation in the accompanying documentation when those details matter.
Chrome’s device mode approximates mobile behavior from a desktop browser; it does not run the page on a physical phone. Check on real hardware when device-specific rendering, touch input, or performance is material. Chrome’s device mode guide describes this limitation and the available emulation controls.
3. Capture repeatable screenshots with Playwright
Playwright is useful when you need the same capture regenerated after a code change, or need a known set of viewport sizes. The example below uses Node.js and the Playwright library. It opens the same URL at mobile and desktop dimensions and saves viewport and full-page images for each. The viewport and full-page files are intentionally separate.
Install and run
mkdir breakpoint-shots
cd breakpoint-shots
npm init -y
npm install playwright
npx playwright install chromium
Save this as capture.mjs, replacing the example URL with the page you document:
import { chromium } from 'playwright';
const url = 'https://example.com';
const captures = [
{ name: 'mobile-375x812', width: 375, height: 812 },
{ name: 'desktop-1440x900', width: 1440, height: 900 },
];
const browser = await chromium.launch({ headless: true });
try {
for (const capture of captures) {
const page = await browser.newPage({
viewport: { width: capture.width, height: capture.height },
deviceScaleFactor: 1,
});
await page.goto(url, { waitUntil: 'networkidle', timeout: 60_000 });
await page.screenshot({
path: `page-${capture.name}-viewport.png`,
fullPage: false,
animations: 'disabled',
});
await page.screenshot({
path: `page-${capture.name}-full-page.png`,
fullPage: true,
animations: 'disabled',
});
await page.close();
}
} finally {
await browser.close();
}
Run it with:
node capture.mjs
The Playwright screenshot API supports full-page capture and other controls such as format, clipping, and scale. Its emulation settings can include device parameters as well as viewport overrides. See the official Playwright screenshots guide and Playwright emulation guide.
Capture actual breakpoint widths
If the goal is to show a responsive transition, first find the breakpoint in DevTools or the page’s CSS, then add captures immediately on both sides of it. For a breakpoint at 768 CSS pixels, for example, capture 767 and 768 pixels if the documentation needs to show which rule applies at the boundary. CSS media queries can use min-width or max-width, so verify the actual condition rather than assuming which side is mobile.
Change the captures array in the script to include those widths. Use a fixed height for a controlled comparison and set fullPage to false for screen views. The example also creates tall full-page versions for readers who need the whole layout.
4. Choose viewport, device emulation, and image scale deliberately
- CSS viewport size: Width and height determine which CSS layout rules are active. Record them with every screenshot.
- Device profile: A device preset can also emulate properties such as user agent, screen size, viewport, and touch capability. Use it when the documentation concerns a particular device profile; use explicit dimensions when the question is about a breakpoint width.
- Device pixel ratio and screenshot scale: These affect output pixel dimensions. Keep them consistent across a comparison so that image size differences do not obscure layout differences. The Playwright script sets
deviceScaleFactor: 1for predictable output dimensions. - Orientation: Capture landscape separately if it is part of the documented behavior; do not imply a portrait capture represents both.
- Page state: Make sure the same content, consent state, and interaction state are visible at each size. If the page requires a click or login, automate that setup before capturing or document the state.
Playwright’s device presets provide a starting point, and the viewport can be overridden. For breakpoint documentation, explicit viewport dimensions make the comparison easy to reproduce. Playwright’s emulation documentation describes device parameters and viewport overrides.
5. Make the image useful as documentation
- Use descriptive, stable filenames such as
checkout-mobile-375x812-viewport.png. - State the URL, viewport width × height, browser, capture mode, and device emulation in a nearby caption or note.
- Use the same viewport heights and screenshot scale for visual comparisons unless the vertical shape is itself the point.
- Capture widths around the actual breakpoint when explaining a transition. A generic “mobile” and “desktop” pair may not reveal where the layout changes.
- Keep viewport-only and full-page images distinct in filenames, captions, and any comparison set.
- For important device-specific behavior, verify the page on physical hardware in addition to desktop emulation.
6. Troubleshoot common capture problems
| Symptom | Likely cause | Fix |
|---|---|---|
| The mobile screenshot still shows the desktop layout | The viewport width was not set as intended, the page has a different breakpoint, or the page was not re-rendered after resizing. | Check the displayed width in DevTools, inspect the media-query bars or CSS, and reload at the target width. In Playwright, create a new page with the desired viewport before navigation. |
| The screenshot is too short or cuts off content | A viewport capture was taken instead of a full-page capture. | Use DevTools’ full-size capture or Playwright’s fullPage: true. Keep the filename marked as full-page. |
| The screenshot is unexpectedly tall | Full-page mode captured the entire scrollable document. | Use viewport mode for the visible screen. The two capture modes are separate artifacts. |
| Images or fonts are missing | Assets had not loaded, lazy content was never brought into view, or the site blocked the browser request. | Wait for the relevant assets or page state before capture. For lazy-loaded sections, scroll through the page before a full-page capture and allow content to load, then capture again. |
Playwright times out waiting for networkidle |
Analytics, chat, streaming, or other requests keep the page active. | Use a more suitable navigation condition such as domcontentloaded, then wait for a meaningful selector or a short, deliberate delay before capture. Check the final image for incomplete content. |
| Two screenshots look different despite the same width | Content, height, browser state, animation, fonts, device scale, or network timing changed between runs. | Keep the viewport, scale, browser, URL, and page state fixed; disable animations in Playwright; wait for required content; and recapture. |
| The image dimensions do not equal the CSS viewport dimensions | Device pixel ratio or screenshot scale changes output pixel dimensions. | Record CSS dimensions separately from file pixel dimensions, and keep the scale setting consistent across the set. |
| Emulation looks different from a phone | Desktop device mode is an approximation and does not reproduce every hardware, browser, input, or performance condition. | Validate on a real device when those differences matter. |
7. Performance, reliability, and cost
A small set of manual DevTools captures has almost no setup cost. Playwright adds installation and browser startup time but makes repeated captures easier to reproduce. A full-page screenshot can require more rendering and image memory than a viewport screenshot, especially for long pages. Capture only the mode and widths the documentation needs, and avoid launching a separate browser for each URL when automating a larger set.
For dependable comparisons, use the same browser version and settings, wait for the content that matters, and avoid depending solely on a generic network-idle condition on pages with persistent requests. Browser automation reproduces the configured environment; it does not guarantee identical output if page content, third-party resources, fonts, or dynamic data change. Keep a note of the capture date when the page itself changes frequently.
Or skip the browser setup
ScreenshotNeo can return a webpage screenshot from one GET request. The API supports explicit viewport sizes and full-page capture, so you can save breakpoint images without managing a browser locally. See the ScreenshotNeo API documentation for 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}`);
Add the target page URL and viewport parameters from the API documentation for each breakpoint you want to save. ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed; an MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Sign up free for ScreenshotNeo.
FAQ
How do I take a screenshot of a website on mobile and desktop?
Set a mobile viewport and a desktop viewport in Chrome DevTools or Playwright, capture each, and label both dimensions and capture modes. For one-off documentation, DevTools is sufficient; for repeat captures, use Playwright.
How can I capture a full-page screenshot at a specific viewport width?
Set the viewport width first, then use DevTools’ full-size screenshot command or Playwright’s fullPage: true. The viewport width still controls responsive CSS while full-page mode captures the vertical document.
What width counts as mobile?
There is no universal mobile breakpoint. Use the page’s own media queries or the width relevant to the device and reader scenario. Chrome presets are samples, not a standard for every site.
Does a mobile-emulated screenshot prove the page works on a phone?
No. Emulation is useful for repeatable layout evidence, but it is an approximation. Check real hardware when touch behavior, device rendering, or performance affects the documentation.


