How to Test an Indian Shopping Website Screenshot on a 6.5-Inch Phone Viewport

A 6.5-inch screen diagonal does not define a browser viewport. To test an Indian shopping website, set the intended CSS width and height directly in Chrome DevTools, choose mobile device mode and a separate device pixel ratio (DPR), then capture and inspect the page. If you are testing a named phone, use its reported CSS viewport dimensions; otherwise label your width and height as a test scenario. Device emulation is a useful first pass, but important behavior should also be checked on a real phone.

1. Choose a meaningful viewport

Screen diagonal is only one physical measurement. Aspect ratio, browser controls, display scaling, and the mapping of physical pixels to CSS pixels all affect the browser’s usable viewport. There is no universal CSS resolution for every 6.5-inch phone. Chrome DevTools lets you enter a custom responsive width and height and set DPR separately. See Chrome’s device mode documentation.

For a named device, get its CSS viewport dimensions from the device or a reliable device specification, and record them with the test. For a general check, select a width and height that represent the layout you want to examine and call it a scenario, for example “narrow mobile portrait.” Do not describe an arbitrary width as the definition of a 6.5-inch phone.

Keep these settings distinct

Viewport width and height: CSS pixels available to the page; these drive responsive layout and media queries.
Device type: Mobile mode can emulate mobile rendering and touch events.
DPR: The ratio of physical screen pixels to logical CSS pixels. It affects high-density drawing and asset rendering, not the CSS viewport dimensions.
Orientation: Portrait and landscape can expose different layout behavior even on the same device.

2. Set up Chrome DevTools

Open the shopping page in Chrome and open DevTools.
Turn on the device toolbar. Choose Responsive mode.
Enter the target width and height in the dimension fields. Record the values and whether they came from a named phone or a test scenario.
Set the device type to mobile when checking mobile rendering and touch behavior.
Set DPR independently when checking high-density rendering. If you are checking layout breakpoints, keep the CSS dimensions as the controlled variable.
Inspect the displayed media-query breakpoints. Repeat at a nearby narrower and wider width to catch transitions and overflow.
Rotate the emulated viewport to check landscape where relevant.

Chrome describes Device Mode as a first-order approximation of a mobile device. Emulation does not reproduce every physical-device, browser, or hardware behavior, so use a real phone when those differences matter.

3. Capture the screenshot

Use a viewport screenshot to review the first visible screen. Use DevTools’ full-size screenshot option when you need to inspect the whole page beyond the viewport. Keep the viewport dimensions, DPR, orientation, page URL, and capture time with the image so another tester can reproduce the view.

Before comparing captures, make the page state consistent: wait for the product content to load, select the same variant, and dismiss or record any consent dialog. A screenshot is a record of one state, not proof that controls work. Test interactions separately.

4. Inspect the shopping page

Review the image at the chosen CSS width and check whether a shopper can understand and use the product page:

Is the product image visible and appropriately sized?
Can the title, price, selected variant, stock status, and delivery information be read without clipping?
Is the primary purchase control visible and reachable?
Do product cards, text, prices, or delivery details overlap or get cut off?
Do menu, search, cart, and checkout controls remain reachable?
Do dialogs, sticky bars, chat widgets, or banners cover important content?
Does the page unexpectedly scroll horizontally?
Do images and text remain sharp at the chosen DPR?

Then interact with the page: open navigation, choose a product option, add the item to the cart, and follow the site’s available checkout steps. For an Indian store, use valid test data and the site’s actual delivery and payment options. Do not assume that one checkout flow or payment method applies to every Indian store.

5. Repeat across widths and conditions

A single screenshot can miss a breakpoint. Repeat the capture at a nearby narrower and wider viewport, and check portrait and landscape when those orientations matter. Compare wrapping, content visibility, overflow, and changes in the layout. Chrome DevTools can display media-query breakpoints and rotate the emulated viewport.

For pages with loading or interaction problems, use DevTools’ network and CPU throttling controls to see how the page behaves under constrained conditions. Record the selected conditions; a throttled capture and an unthrottled capture are different test cases.

6. Know when to use a real phone

Use a physical phone for important checks where touch behavior, browser differences, hardware, or actual device settings could change the result. Chrome recommends trying the page on an actual mobile device when in doubt; India’s Guidelines for Indian Government Websites and apps also recommend testing with physical devices, emulators, or browser-based tools.

Emulation is efficient for repeatable viewport and breakpoint checks. A real phone complements it by showing behavior in the actual browser and device environment. Do not treat a screenshot from DevTools as proof that every phone with a 6.5-inch diagonal will show the same layout.

7. Automate a repeatable capture

For a local browser workflow, a small Playwright script can set an explicit CSS viewport and DPR, load the page, and save a screenshot. Install Playwright and its browser first using the official Playwright setup instructions, then save this as capture.mjs. Set TEST_URL to a page you are authorized to access and change the viewport values to your documented test scenario.

import { chromium } from 'playwright';

const url = process.env.TEST_URL;
if (!url) throw new Error('Set TEST_URL to the page to capture');

const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({
  viewport: { width: 390, height: 844 },
  deviceScaleFactor: 2,
  isMobile: true,
  hasTouch: true,
});
const page = await context.newPage();
await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
await page.screenshot({ path: 'shopping-page.png' });
await browser.close();

The example uses 390 by 844 CSS pixels as an illustrative scenario, not a universal 6.5-inch resolution. Change it to the target phone’s reported CSS dimensions or your explicitly named test case. Some shopping sites keep network requests open, so networkidle may never occur; if that happens, wait for a meaningful product selector instead of treating network idle as required.

Equivalent API request examples

These examples capture a URL through ScreenshotNeo. Replace the URL with the page under review and provide your API key. The API returns an image response; these minimal examples save its body.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -d width=390 \
  -d height=844 \
  -d device_scale_factor=2 \
  -o shopping-page.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={
        "access_key": "YOUR_API_KEY",
        "url": "https://example.com",
        "width": 390,
        "height": 844,
        "device_scale_factor": 2,
    },
    timeout=90,
)
r.raise_for_status()
with open("shopping-page.webp", "wb") as f:
    f.write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com',
  width: '390',
  height: '844',
  device_scale_factor: '2',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(({ writeFile }) =>
  writeFile('shopping-page.webp', Buffer.from(await res.arrayBuffer()))
);

Use the parameter names documented by the API for the exact settings you need; the examples illustrate explicit viewport and density values. Keep API keys out of source control and client-side code. See the ScreenshotNeo API documentation for request options and response details.

Or skip the browser setup

ScreenshotNeo can capture a page with one API request. Set the viewport and DPR using the API options when you need a particular mobile test scenario:

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

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. See the API documentation for capture settings and available parameters.

Troubleshooting

Symptom	Likely cause	What to do
The layout does not look like the target phone	The diagonal was used as a proxy for CSS dimensions, or DPR was mistaken for viewport size.	Set the target CSS width and height explicitly. Adjust DPR separately and record both.
Desktop navigation appears in the mobile capture	The viewport is wider than the site’s mobile breakpoint, or the page has not applied the expected responsive layout.	Confirm the CSS dimensions and inspect media-query breakpoints. Test adjacent widths.
Text or images look soft	The selected DPR or image assets do not match the density being reviewed.	Set DPR separately from viewport size and inspect the source assets at the intended density.
Content is cut off or overlaps	A breakpoint, fixed-width element, sticky control, or overlay is not fitting the viewport.	Capture nearby widths, inspect horizontal overflow, and check sticky bars and dialogs.
Automated browser capture hangs waiting for the page	Long-lived requests can prevent a network-idle condition.	Wait for a meaningful product-page selector or a bounded delay, and use an explicit timeout.
The emulated page works, but the phone behaves differently	Device emulation is an approximation and cannot reproduce every physical-device condition.	Repeat the important interaction on the physical phone and record its browser and settings.
Screenshot API request fails	The key, URL encoding, request options, or target page load may be invalid.	Check the status and response headers, verify the key and encoded URL, and consult the API docs for supported parameters and page verdicts.

Performance, reliability, and cost

Keep comparisons controlled: use the same URL, viewport, DPR, orientation, and page state when comparing captures.
Automate only stable conditions: wait for a product-specific element when network activity does not settle, and use a timeout so a capture cannot hang forever.
Test more than one width: adjacent widths make breakpoint regressions easier to catch than repeated captures at one size.
Use real devices selectively: reserve physical-phone checks for critical touch and browser behavior that emulation cannot establish.
Budget for successful captures: ScreenshotNeo states that only clean shots are billed; bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Responses identify page verdict and billing status in headers.
Choose volume by need: ScreenshotNeo’s free plan has 1,000 shots per month; paid tiers range from Starter at $5 for 3,000 to Business at $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan.

FAQ

Does “6.5-inch” tell me the exact screenshot dimensions?

No. It describes a diagonal, not the browser’s CSS viewport. Use dimensions reported for the target phone or label your values as a test scenario.

Should I increase DPR to make the viewport wider?

No. DPR concerns physical pixels per CSS pixel. Change viewport width and height to test responsive layout.

Is a full-page screenshot enough to validate checkout?

No. It shows page content, but checkout controls and touch interactions need functional testing.

Can an emulated screenshot guarantee the same result on every phone?

No. Emulation is an approximation. Check important behavior on the actual device when hardware or browser differences could matter.