How to Set the Right Viewport Size for Website Screenshot Automation in India

Set the browser viewport to the width and height, in CSS pixels, that you want to inspect. Choose widths around your site’s actual responsive breakpoints, keep them fixed between runs, and set device pixel ratio (DPR) separately when output pixel density matters. Use a viewport screenshot for the visible screen and a full-page screenshot when you need content below the fold.

There is no single viewport width that represents all visitors in India. This research did not establish an authoritative India-specific viewport distribution. For an India-focused test matrix, use your own dated audience data or a named, dated market dataset rather than assuming a particular device or width is representative.

1. Understand viewport size, DPR, and screenshot dimensions

The viewport is the browser page layout area, measured in CSS pixels. CSS media queries and responsive layout rules respond to that size. DPR describes the relationship between physical screen pixels and logical CSS pixels; it is a separate setting. A viewport of 375 CSS pixels does not, by itself, say how many physical or image pixels the screenshot will contain.

Keep three questions separate:

Layout: What CSS viewport width and height should the browser use?
Density: What device scale factor should the emulation use?
Capture scope: Should the result show the visible viewport or the full document?

Chrome DevTools documents convenient responsive widths of 320, 375, 425, 768, 1024, 1440, and 2560 pixels. These are tool presets, not evidence of audience shares. Use them as starting points, then tailor the matrix to your breakpoints and audience.

2. Choose widths that exercise your responsive layout

Inspect your CSS breakpoints or use DevTools’ media-query indicators to find where the layout changes.
Test at each important breakpoint and just below and above it. A breakpoint at 768 CSS pixels, for example, is a reason to check widths on both sides as well as at the transition.
Add a narrow mobile case and a wider mobile content case. Include a tablet or compact desktop width only if your design changes meaningfully there, and include a desktop case.
Choose height based on what you need to inspect: the first screen, a particular fold, or an interaction that depends on available vertical space.
Keep the chosen dimensions stable and record them with each screenshot so visual comparisons use the same inputs.

A 375 × 812 viewport is a useful illustrative test case, not a claim about the most common Indian phone. The right matrix depends on the site’s own breakpoints and audience evidence.

3. Set a viewport explicitly in Playwright

Playwright device descriptors include viewport settings. If you use a device preset and want custom dimensions, put the explicit viewport after the device spread so your override takes precedence.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [{
    name: 'mobile-layout-check',
    use: {
      ...devices['Pixel 9'],
      // Explicit dimensions override the preset viewport.
      viewport: { width: 375, height: 812 },
    },
  }],
});

This config sets the browser context’s viewport. To change pixel density independently, configure deviceScaleFactor in the project’s use options. Device presets can also supply emulation settings such as user agent and touch support; use the settings that your test actually needs and record them alongside the viewport. See the official Playwright emulation documentation.

You can also set the viewport when creating a browser context. This runnable example uses Chromium and captures both the visible viewport and full page:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const context = await browser.newContext({
  viewport: { width: 375, height: 812 },
  deviceScaleFactor: 1,
});
const page = await context.newPage();
await page.goto('https://example.com', { waitUntil: 'load' });
await page.screenshot({ path: 'viewport.png' });
await page.screenshot({ path: 'full-page.png', fullPage: true });
await browser.close();

Install Playwright and its browser binaries using the commands in the official Playwright getting-started guide. If your project already has Playwright configured, add the script to that project and use its existing browser installation.

4. Use Chrome DevTools for a manual responsive check

Open the page in Chrome and open DevTools.
Turn on Device Mode.
Enter the desired width and height directly, or select a documented responsive preset.
Inspect media-query indicators and the layout at and around your breakpoints.
Capture a screenshot when the rendered state is ready.

Device Mode is an approximation of a mobile experience. If fidelity matters for browser chrome, touch behavior, font rendering, keyboard behavior, or device constraints, check the important journey on a real Android or iOS device. See Chrome’s Device Mode documentation.

5. Pick viewport or full-page capture

A regular screenshot shows the visible viewport. A full-page capture extends beyond the initial viewport to include the document’s content. Use viewport capture for first-screen checks and interactions tied to the visible area. Use full-page capture for long-page reviews or when the complete page is the artifact you need.

Full-page output has different dimensions from a viewport image. Pages with lazy-loaded images or other content that loads as you scroll may need extra care: confirm the content is present before treating the capture as complete. Keep capture scope consistent when comparing screenshots.

6. Check the page’s mobile viewport declaration

If a page does not lay out as expected on mobile, check that its HTML includes a mobile viewport declaration. Chrome’s mobile viewport criteria describe a width value such as device-width and an initial-scale value of at least 1.

<meta name="viewport" content="width=device-width, initial-scale=1">

Without an appropriate declaration, a narrow emulated viewport may not trigger the layout behavior you expect. See Chrome’s mobile viewport guidance.

7. Build an India-focused test matrix from evidence

Start with a compact, repeatable matrix that covers the site’s responsive transitions, then add cases based on your product’s first-party audience analytics. Record the source and date of any market dataset used. Do not label a preset width as representative of India without supporting data.

Test input	How to choose it	What it helps reveal
Narrow mobile width	Choose a small CSS width relevant to the design; 320px is one DevTools preset.	Overflow, cramped controls, and narrow-screen layout issues.
Breakpoint-adjacent widths	Test just below, at, and above important CSS breakpoints.	Unexpected layout switches and boundary bugs.
Wider mobile width	Choose a width where mobile content has more room; 375px and 425px are presets.	Text wrapping, spacing, and component behavior at another mobile width.
Tablet or compact desktop	Add only where your layout has a meaningful transition; 768px and 1024px are presets.	Navigation and column changes between mobile and desktop patterns.
Desktop width	Choose the widths your design supports; 1440px is a preset.	Wide layout, max-width behavior, and desktop composition.

These values are test inputs, not recommended national defaults. If your analytics identify an important audience segment or device, add a test that covers it and state the evidence behind that choice.

8. Make screenshot runs reproducible

Fix viewport width and height for every comparison.
Record browser engine, device emulation, and DPR with the screenshot artifact.
Keep capture scope consistent: viewport screenshots and full-page screenshots have different output dimensions.
Use the same page state and wait condition across runs; animations, late fonts, and asynchronous content can change pixels.
When a result differs from a real phone, use a physical device to investigate rather than assuming desktop emulation is exact.

Or skip the browser setup

ScreenshotNeo takes a screenshot through one API request. The code below requests a WebP capture of a page at a chosen viewport. See the ScreenshotNeo documentation for API options.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com", "width": 375, "height": 812},
    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',
  width: '375',
  height: '812',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Replace YOUR_API_KEY with your key and change the URL and dimensions to match your test. Cookie and consent banners are accepted, and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before capture; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers state the page verdict and billing outcome. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Every feature is on every plan. Learn more at ScreenshotNeo.

Troubleshooting

The page looks desktop-sized in a mobile screenshot

Check the page’s viewport meta element and verify that the browser context is using the intended CSS viewport. The mobile viewport guidance is documented by Chrome.

The configured dimensions do not take effect

When spreading a Playwright device preset, put your explicit viewport afterward. A later preset spread can replace earlier values. Confirm the running project is the one whose configuration you edited.

The layout changes between repeated captures

Keep viewport, DPR, browser engine, emulation settings, page state, and capture scope fixed. Wait for relevant content to load and check for animation or asynchronous updates.

The full-page screenshot is much taller than expected

Full-page capture includes content beyond the visible viewport. Use a regular viewport screenshot when you only need the first screen; inspect long-page output separately.

Lazy-loaded content is missing

Some page content loads only after scrolling or other interaction. Ensure the content has loaded before capture, and verify the page’s final state rather than assuming a full-page operation will render every lazy resource in advance.

Emulation does not match a physical phone

Device Mode approximates the mobile experience. Check on a real Android or iOS device when touch, browser chrome, keyboard behavior, font rendering, or hardware constraints matter.

Performance, reliability, and cost

A small matrix of targeted widths is usually easier to maintain than capturing every possible size. Focus on actual breakpoints and the user journeys where layout matters. Full-page captures can produce much larger images than viewport captures, so use them only when the additional page content is part of the task.

For reliable comparisons, preserve the capture inputs and page state, and investigate failed or incomplete loads before accepting a screenshot as a valid visual result. The research provides no benchmark for capture speed or cost and no India-specific viewport share, so neither should be inferred from the preset list.

FAQ

What viewport size should I use for mobile screenshots?

Use widths that cover your breakpoints and audience evidence. There is no single width established here as representative of all Indian visitors.

Does device scale factor change viewport size?

No. Viewport dimensions are CSS pixels; DPR or device scale factor controls pixel density separately.

Should automated visual tests use a device preset?

Use one when its emulation settings match the behavior under test. For custom dimensions, set the explicit viewport after the preset spread.

When should I capture the full page?

Use full-page capture when the artifact needs content outside the initial viewport. Use viewport capture for the visible screen or first-fold checks.

How can I decide which widths matter for Indian users?

Use first-party audience analytics or a named, dated market dataset. The cited research does not establish a nationally representative viewport distribution.