How Big Should a Website Screenshot Be?

Use the target viewport, not one universal screenshot size. Start with 1366×768 or 1920×1080 for desktop, about 375×812 for phones, and 768px wide for tablets when the layout changes. Use a viewport screenshot to show what fits on screen; use a full-page screenshot for documentation, review or content below the fold.

The right dimensions depend on the audience, the responsive breakpoints you need to test, and where the image will be displayed. A screenshot for visual QA has different requirements from a screenshot embedded in documentation.

Quick size recommendations

Purpose	Starting dimensions	Why
General desktop view	1366×768	Representative laptop viewport and a documented screenshot preset
Large desktop view	1920×1080	Shows a wide-monitor layout
Responsive desktop test	1024×768 and 1440×900	Catches layout changes between laptop and larger desktop widths
Phone	375×812	Representative modern mobile viewport
Small phone	320×568 or 320×812	Exposes cramped navigation and text wrapping
Large phone	425×844	Checks the upper end of common phone widths
Tablet	768×1024	Useful when tablet-specific navigation or grids exist

These are practical starting points documented by Chrome DevTools and screenshot tooling, not universal web standards. Test the widths where your layout changes rather than optimizing for one monitor resolution.

Viewport screenshot or full-page screenshot?

Choose a viewport screenshot when

You need to show the first screen a visitor sees.
You are checking responsive layout, navigation, spacing or above-the-fold content.
The screenshot will be compared across devices or visual regression runs.
The image must fit a fixed presentation frame.

Choose a full-page screenshot when

You are documenting an entire page.
A design review needs content below the fold.
You are archiving a page or creating a report.
The page is long and the reader needs one complete reference image.

A viewport capture has a fixed CSS width and height. A full-page capture covers the scrollable document and may be much taller than the visible browser area. Full-page captures can expose lazy-loading, sticky-header and animation problems that a viewport capture hides.

CSS pixels, physical pixels and device pixel ratio

Choose dimensions in CSS pixels first. CSS pixels determine the responsive layout. Device pixel ratio (DPR) controls how many physical pixels are used to draw each CSS pixel, so a DPR of 2 can produce an export twice as wide and twice as tall without changing the page’s layout width.

CSS viewport	DPR	Approximate raster size
1366×768	1	1366×768
1366×768	2	2732×1536
375×812	2	750×1624

Use a higher DPR when small text or fine UI details must remain clear in a review or article. It increases file size and processing work, so do not use it as a substitute for choosing the correct CSS viewport.

Match dimensions to responsive breakpoints

Do not capture only the physical resolution of the monitor you own. Capture the widths at which your CSS changes:

List your media-query and container breakpoints.
Capture just below each breakpoint.
Capture exactly at the breakpoint.
Capture just above it.
Include a representative phone, tablet and desktop width for the audience.

A practical matrix is 320, 375, 425, 768, 1024, 1366, 1440 and 1920px wide. You do not need every value for every page; add widths where navigation, columns, typography or media behavior changes.

Responsive pages should allow vertical scrolling while avoiding accidental horizontal scrolling. Google Chrome guidance recommends that images use max-width: 100% so they shrink to fit their container, with explicit width and height attributes so the browser can reserve space before loading.

How to capture the sizes yourself

Chrome DevTools

Open the page in Chrome.
Open DevTools and enable Device Mode.
Select a preset such as Mobile S (320px), Mobile M (375px), Mobile L (425px), Tablet (768px), Laptop (1024px), Laptop L (1440px) or 4K (2560px).
Set a custom width and height when your breakpoint or publication frame requires it.
Set the DPR when you need a high-resolution export.
Choose the capture command for the visible area or the complete page.

For a reproducible review, record the URL, CSS viewport, height, DPR, color scheme, browser version and capture date.

Playwright example

import { chromium } from 'playwright';

const sizes = [
  { name: 'phone', width: 375, height: 812, deviceScaleFactor: 2 },
  { name: 'tablet', width: 768, height: 1024, deviceScaleFactor: 1 },
  { name: 'desktop', width: 1366, height: 768, deviceScaleFactor: 1 },
  { name: 'large-desktop', width: 1920, height: 1080, deviceScaleFactor: 1 }
];

const browser = await chromium.launch();
for (const size of sizes) {
  const page = await browser.newPage({
    viewport: { width: size.width, height: size.height },
    deviceScaleFactor: size.deviceScaleFactor
  });
  await page.goto('https://example.com', { waitUntil: 'networkidle' });
  await page.screenshot({
    path: `shot-${size.name}.png`,
    fullPage: false
  });
  await page.close();
}
await browser.close();

Set fullPage: true when the goal is the entire document. For dynamic pages, wait for a known selector or application-ready state instead of assuming that network idle means every image or chart is finished.

Screenshot dimensions for documentation and articles

The delivered image should fit the content column. Google’s style guidance uses an 856px main-body column as an example and gives 1712px as a suitable 2× source width. If your article column is 856px, export or store a source around 1712px wide when text needs to remain sharp, then render it at the column width.

Do not display a 1920px image at 1920px inside an 856px column.
Crop or resize after capture only when the crop does not remove information needed by the reader.
Preserve the original capture for future crops and higher-density displays.
Use a descriptive filename and record the viewport in the caption, such as “1366×768 desktop viewport.”

Website screenshots versus other website images

A browser screenshot is a rendered viewport or document. It is not the same asset as a hero image, banner or background. Shopify’s content guidance suggests values such as 1280×720 for a desktop hero, 360×200 for a mobile hero, 1200×800 for a blog image and 1200×400 for a banner. Those are publishing recommendations, not requirements for the browser viewport. Capture the page at the viewport your layout needs, then place or crop it to the publishing slot.

Special case: web app manifest screenshots

Manifest screenshots have separate constraints. Chrome guidance specifies at least 320px and at most 3840px in each dimension, with the maximum dimension no more than 2.3 times the minimum. Use wide and narrow form factors to represent desktop and mobile arrangements when your manifest needs both.

ScreenshotNeo options for exact dimensions

ScreenshotNeo is a website screenshot API and MCP server. It supports custom viewports, 12 device presets, retina scale, full-page capture, element capture by CSS selector, image resizing, dark mode, transparent backgrounds and PDF output. You can also wait for a selector, delay or network idle; load lazy images for full-page captures; hide selectors; click an element; and set custom headers, cookies, user agent, authorization, timezone and geolocation.

For repeatable captures, choose a CSS viewport that matches your test case, then set retina scale only when the output needs extra raster detail. Use full-page mode for documentation and viewport mode for first-screen comparisons. See the ScreenshotNeo documentation for the current request options and response details.

Or skip the browser setup

One GET request returns a PNG, JPEG, WebP or PDF. The following examples use WebP and the required 1366×768-style target URL; add the viewport, full-page and other options from the documentation for your capture.

cURL

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

Python

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)

Node.js

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, newsletter popups and chat widgets are removed before the shot. Bot checks, blank pages and failed loads are never billed, and response headers identify the page verdict and whether it was billed. An MCP server provides take_screenshot, get_page_info and capture_pdf tools for Claude, Cursor and other MCP clients. 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 and start with 1,000 screenshots per month at no cost.

Performance, reliability and cost considerations

Viewport height: Very tall full-page captures use more memory and take longer than a viewport shot.
Retina scale: A 2× export has roughly four times as many pixels as a 1× export, increasing transfer and storage size.
Lazy content: Wait for the relevant selector or load lazy images before capturing a complete page.
Animations: Freeze or hide animated elements when comparing screenshots; otherwise two captures can differ without a code change.
Caching: Reuse cached captures for repeated documentation images when freshness allows it.
Billing: ScreenshotNeo bills only clean shots; cache hits, bot checks, blank pages, timeouts and failed loads cost nothing.
Batch work: Use bulk capture for up to 100 URLs per call when generating a consistent set of screenshots.

Troubleshooting

Symptom	Likely cause	Fix
Horizontal scrolling appears	The CSS viewport is narrower than a fixed-width element	Inspect the overflowing element, use fluid widths and apply `max-width: 100%` to images.
Mobile navigation is missing	The capture width is above the mobile breakpoint	Capture at 320–425px and verify the breakpoint in DevTools.
Text is blurry in an article	The source has too few physical pixels	Capture at a higher DPR or use a 2× source, then render it to the column width.
Full-page image misses content	Lazy images or client-rendered sections were not ready	Wait for a selector, delay or network idle, and confirm the content is present before capture.
Sticky header repeats unexpectedly	Full-page stitching captures a fixed element more than once	Hide the sticky selector for documentation or use a viewport capture when repetition is useful.
Two captures differ	Animation, time-dependent content, ads or personalized data changed	Disable animation, block changing resources, set cookies and headers, and use a consistent viewport.
ScreenshotNeo response is not billed	The page was blank, timed out, failed, hit a bot check or came from cache	Inspect `X-Page-Verdict` and `X-Billed`; fix access or loading conditions before retrying.

Recommended capture checklist

Define whether the goal is first screen, responsive QA or full documentation.
Choose CSS width and height from the target device or breakpoint.
Include phone, tablet and desktop widths when layouts differ.
Set DPR separately from CSS dimensions.
Wait for content that loads after navigation.
Check for horizontal overflow and repeated sticky elements.
Keep article images within the content column.
Store the original high-resolution capture and record its viewport.

FAQ

Is 1920×1080 the best website screenshot size?

Only when you need to represent a large desktop monitor. For a general laptop view, 1366×768 is a more practical starting point.

What size should a mobile screenshot be?

Start at 375×812, then check 320px and 425px widths when phone layout behavior matters.

Should screenshots use a 2× scale?

Use 2× when small text must stay sharp in a resized document or review. Keep the CSS viewport unchanged.

How wide should a screenshot be in documentation?

Display it no wider than the content column. Keep a source around 2× that width when readers need crisp text.

Do I need both viewport and full-page screenshots?

Use both when you need to show the visitor’s first screen and document content below the fold. Otherwise choose the mode that matches the communication goal.