How to Test Responsive Screenshots of an Indian Web App at 375 Pixel Width

To test an Indian web app at 375 pixels wide, set the browser viewport to 375 CSS pixels, choose and record a viewport height and device pixel ratio (DPR), then inspect the page and capture either the visible viewport or the full page. Use the app’s actual CSS breakpoints to test nearby widths too. The 375-pixel setting is a Chrome DevTools preset, not a standard or a claim that all Indian phones use that width.

1. Set up a reproducible 375px test

In Chrome DevTools

Open the app in Chrome and open DevTools.
Turn on Device Mode, then select Responsive.
Set the viewport width to 375 CSS pixels and enter a height. Record both values; the same width with a different height can show different visible content.
Record the device scale factor or DPR used for the capture. CSS pixels describe the layout viewport; DPR determines how those logical pixels map to raster pixels, so a 375 CSS-pixel viewport need not produce a 375-pixel-wide image.
Inspect the page at 375px. Also inspect widths on either side of each relevant media-query breakpoint. Chrome DevTools can show media-query ranges so you can find the transitions that matter to this app.
Capture the visible viewport for the initial screen, or capture the full page if the review includes content below the fold. Note which scope you captured.

See the [Chrome DevTools Device Mode guide](https://developer.chrome.com/docs/devtools/device-mode/), which documents responsive dimensions, media queries, and capture controls.

Choose Indian browser conditions deliberately

There is no single locale, timezone, or geographic setting that is correct for every Indian web app. Choose these based on the behavior under test: for example, an Indian-language experience, timezone-dependent content, or a location-specific page. Record the exact locale, timezone, geolocation, and permission state where they affect the result. Do not treat a chosen setting as representative of every user in India.

2. Automate repeatable screenshots with Playwright

For regression checks, pin the viewport and browser context settings in code. The example below uses Chromium, a 375 by 812 CSS-pixel viewport, DPR 1, and an optional Indian locale and timezone. Change the locale and timezone to match the test case. It captures both the viewport and full page; keep only the capture you need if storing two files is unnecessary.

import { chromium } from 'playwright';

const browser = await chromium.launch();
const context = await browser.newContext({
  viewport: { width: 375, height: 812 },
  deviceScaleFactor: 1,
  locale: 'en-IN',
  timezoneId: 'Asia/Kolkata',
});
const page = await context.newPage();

await page.goto('https://example.com', { waitUntil: 'networkidle' });
await page.screenshot({ path: 'mobile-375-viewport.png' });
await page.screenshot({ path: 'mobile-375-full.png', fullPage: true });

await browser.close();

Install Playwright in your project and install its browser as described in the [official Playwright library documentation](https://playwright.dev/docs/library). Replace the example URL with your app. If the app keeps long-lived network connections open, `networkidle` may not be a suitable readiness condition; wait for a page-specific selector or use another explicit readiness check.

Test an actual breakpoint transition

A single 375px capture can miss a layout bug just above or below a breakpoint. Find the app’s breakpoint values in its CSS or use DevTools’ media-query display, then capture the neighboring widths that exercise both sides. For example, if a layout changes at 400px, test 399px and 400px (and include 375px if it is a required target). Substitute the actual breakpoint; 400px is only an illustration.

Set other browser conditions only when needed

Playwright browser contexts can also emulate geolocation and grant permissions. Add these only for a scenario that uses location or permission-dependent behavior, and document the coordinates and permission state:

const context = await browser.newContext({
  viewport: { width: 375, height: 812 },
  deviceScaleFactor: 2,
  locale: 'hi-IN',
  timezoneId: 'Asia/Kolkata',
  geolocation: { latitude: 19.076, longitude: 72.878 },
  permissions: ['geolocation'],
});

The example coordinates are an explicit Mumbai test location, not a default for Indian users. For an app without location-dependent behavior, omit geolocation and the permission.

3. Compare screenshots consistently

Keep the capture conditions fixed: URL, viewport width and height, DPR, browser version, locale, timezone, geolocation, permissions, and capture scope.
Wait for the relevant content: a screenshot taken before fonts, images, or client-rendered content settle may differ between runs. Prefer a page-specific readiness condition when network-idle waiting is unreliable.
Check both layout and raster output: compare wrapping, overflow, navigation, and touch-sized controls at the CSS viewport; compare image dimensions and pixel output with the same DPR.
Include content below the fold when needed: viewport and full-page screenshots answer different review questions. Lazy-loaded content may require scrolling or an appropriate full-page capture method.
Validate high-impact behavior on a phone: desktop emulation is a useful first pass, but it does not run the page on an actual mobile device. Confirm device-specific rendering, performance, and interaction on real hardware when fidelity matters.

4. Troubleshooting

Symptom	Likely cause	Fix
Screenshot width is not 375 physical pixels	375 is the CSS viewport width; DPR scales raster output.	Record DPR and compare captures made with the same scale factor.
Layout looks correct at 375px but breaks nearby	The test covers only one width and misses a media-query transition.	Inspect the app’s breakpoints and capture widths immediately around the relevant transition.
Screenshot misses content below the fold	A viewport capture includes only the visible area.	Use full-page capture and state that scope in review artifacts.
Screenshot is blank or content is missing	The capture may happen before client rendering, fonts, or images finish.	Wait for a relevant selector or other page-specific readiness condition before capturing.
Automated navigation waits indefinitely	The page may keep network activity open, making a network-idle condition unsuitable.	Wait for a specific element or app-ready signal instead.
Localized or regional content differs unexpectedly	Locale, timezone, geolocation, or permission state differs between runs.	Set and record only the browser conditions relevant to the scenario; use the intended test location and permission state.
Emulated result differs from a phone	Device Mode approximates a mobile environment and does not reproduce every device behavior.	Validate important device-specific rendering and interaction on actual hardware.

5. Performance, reliability, and cost

DevTools is a quick manual option for exploring widths and inspecting layout. Playwright adds setup and browser execution time, but makes viewport and browser conditions explicit for repeatable regression captures. Keep a small set of widths tied to real breakpoints rather than capturing arbitrary widths without a reason. A stable readiness condition and fixed capture settings reduce misleading diffs. This workflow uses browser tooling and does not require purchasing a phone; actual-device validation is optional when emulation cannot answer the fidelity question.

Or skip the browser setup

ScreenshotNeo can capture a URL at a chosen viewport through one API request. Its screenshot options include viewport sizing and full-page capture. The service accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides screenshot tools for AI agents.

See the ScreenshotNeo API documentation for configuration details. Example request:

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

ScreenshotNeo has a free plan with 1,000 screenshots a month and no card required. Paid plans start at $5 for 3,000 screenshots. Sign up for 1,000 free screenshots a month.

FAQ

Is 375px the standard mobile width for Indian web apps?

No. It is a convenient Chrome DevTools preset, not a standard or a documented measurement of Indian phone usage. Test the widths and breakpoints relevant to your app.

Should I use a particular Indian locale?

Only choose a locale that matches the behavior you need to validate. For example, use a Hindi locale for a Hindi-language scenario; an English-language scenario may use a different locale. Record it so the capture can be reproduced.

When should I use a real phone?

Use one when device-specific rendering, performance, or interaction matters, or when an emulated result does not answer the question. DevTools describes Device Mode as a first-order approximation.

Does a full-page screenshot replace a viewport screenshot?

No. A viewport capture reviews the currently visible area; a full-page capture includes content outside it. Choose based on what the review needs and label the scope.