How to Test an Indian News Website Screenshot on a 360 Pixel Viewport

To test an Indian news website at a 360-pixel viewport, set the browser viewport to 360 CSS pixels wide, choose and record a fixed height, hold the page state and capture mode steady, then inspect the screenshot for overflow, clipped headlines, overlapping elements, inaccessible navigation, oversized media, and overlays covering the story. A 360 CSS-pixel viewport is a browser layout measurement; it is not necessarily the phone’s physical screen resolution.

Chrome DevTools is a good manual starting point. For repeatable checks, automate the same viewport and page state with Playwright. In either case, treat the screenshot as evidence of one rendered state: emulation does not certify behavior on actual phone hardware.

1. Set up a repeatable 360 CSS pixel test

Open the news page in Chrome and open DevTools.
Turn on Device Mode, choose Responsive, and enter a width of 360. Set a height that matches the test brief and record it. Keep the height consistent when comparing captures.
Record the browser and version, device type, and device pixel ratio (DPR) if those settings matter to the comparison. CSS pixels determine layout width; DPR affects how CSS pixels map to device pixels.
Wait for the same page state before capture. Use the same scroll position and note whether menus, advertisements, consent notices, or subscription prompts are visible. These elements can affect what the screenshot shows.
Choose the capture mode that matches the question: capture the visible viewport for the current screen, or a full-size screenshot to include below-the-fold content.
Inspect the screenshot at its native dimensions. Record the settings and any visible issue so another capture can be compared fairly.

Chrome DevTools supports custom responsive dimensions, device pixel ratio controls, breakpoint inspection, and both viewport and full-page screenshot captures. See Chrome’s Device Mode documentation.

2. Capture with Chrome DevTools

With the page open, open DevTools and enable Device Mode.
Select Responsive and set the width to 360 CSS pixels. Enter and record the height requested for the test.
Set the device type and DPR if required. Avoid changing these between a baseline and a later capture.
Reproduce the intended page state, including scroll position and whether any overlays or navigation menus are open.
Open the DevTools command menu and choose Capture screenshot for the visible viewport, or Capture full size screenshot for the whole page.
Compare like with like: do not treat a viewport capture and a full-page capture as equivalent evidence.

If you are locating a responsive breakpoint, inspect the media-query breakpoints in Device Mode and test widths between them. A single 360-pixel capture can reveal a problem at that width, but nearby widths help show where the layout changes.

3. What to inspect on a narrow news page

Apply these checks to the capture. They are a practical review checklist, not findings about any particular Indian publisher.

Horizontal overflow: Look for content extending beyond the viewport or a horizontal scrollbar. Check the page edges and wide modules such as tables, tickers, or embedded media.
Headlines and text: Check whether headlines wrap naturally, remain legible, and avoid colliding with badges, timestamps, or thumbnails.
Navigation: Confirm that navigation is reachable and that menu controls are visible and not obscured. A screenshot can reveal placement problems; it cannot by itself prove that a control works.
Images and video: Check that media fits the content width, maintains its intended proportions, and does not push adjacent content out of view.
Overlays: Note whether a consent banner, subscription prompt, advertisement, or chat widget obscures the headline or controls. Capture the same overlay state in comparisons.
Visible hierarchy: Check that the lead story, section labels, and supporting content remain distinguishable at this width.
Below-the-fold content: If the test concerns long-page layout, take a full-page capture as a separate artifact and inspect it for gaps, clipping, and content that fails to appear.

4. Check the viewport metadata

A screenshot alone cannot establish whether the page has suitable viewport metadata. Inspect the document head or run Lighthouse’s viewport audit. The audit’s passing condition includes a viewport meta element whose content attribute contains a width= declaration. See Lighthouse’s viewport audit documentation.

If the viewport declaration is missing or unsuitable, the page may not lay out as intended on a narrow device. Confirm the markup or audit result instead of inferring metadata from the rendered image.

5. Automate repeatable screenshots with Playwright

Playwright can emulate device properties, including viewport and screen size. The following runnable Node.js example uses a fixed 360 by 800 viewport, captures the visible viewport, and saves a PNG. Install Playwright and its Chromium browser first:

npm install --save-dev playwright
npx playwright install chromium

Save this as screenshot.mjs and run it with NEWS_URL=https://example.com/news node screenshot.mjs, replacing the URL with the page you are authorized to inspect:

import { chromium } from 'playwright';

const url = process.env.NEWS_URL;
if (!url) throw new Error('Set NEWS_URL to the news page URL');

const browser = await chromium.launch({ headless: true });
try {
  const page = await browser.newPage({
    viewport: { width: 360, height: 800 },
    deviceScaleFactor: 1,
    isMobile: true,
    hasTouch: true,
  });
  await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
  await page.screenshot({ path: 'news-360-viewport.png' });
} finally {
  await browser.close();
}

To save the whole page instead, change the screenshot call to await page.screenshot({ path: 'news-360-full.png', fullPage: true });. Keep browser version, width, height, device settings, page state, and screenshot mode consistent between baseline and new captures. Playwright’s official guide covers available emulation options.

For visual comparisons, use the same route and state where possible. News headlines, timestamps, rotating advertisements, and other dynamic page content can change pixels without indicating a responsive-layout regression. Review image differences in context rather than treating every changed pixel as a defect.

6. Make the comparison meaningful

Before attributing a visual change to the site, compare the capture settings:

Setting	What to keep consistent
Viewport	360 CSS pixels wide and the same recorded height
Device emulation	Device type, DPR, and touch settings
Browser	Browser and version
Capture mode	Viewport-only or full-page
Page state	URL, scroll position, menu state, overlays, and loading state
Review criteria	Overflow, clipping, overlap, text legibility, media sizing, and access to navigation

If one setting differs, state it before interpreting the screenshots. For diagnosis, repeat at nearby widths and note where the layout changes.

7. Limits of desktop emulation

Chrome describes Device Mode as “a first-order approximation of how your page looks and feels on a mobile device.” It also advises that “When in doubt, your best bet is to actually run your page on a mobile device.” Both statements are from Chrome for Developers’ Device Mode documentation.

Use emulation to inspect responsive layout and create repeatable evidence. If the issue depends on touch behavior, browser chrome, performance, or actual hardware, confirm it on a physical phone. Use a phone already available to the team where possible; this procedure does not require buying a particular device.

8. Troubleshooting

Symptom	Likely cause	Fix
The page does not appear to use a narrow layout	Viewport dimensions were not set as intended, or viewport metadata is missing or unsuitable.	Confirm Device Mode is enabled at 360 CSS pixels. Inspect the document head or run Lighthouse’s viewport audit.
Two screenshots are difficult to compare	Height, DPR, browser, page state, scroll position, or capture mode changed.	Record those settings and recapture with matching values.
A full-page image differs greatly from a viewport image	The captures show different amounts of the document.	Compare viewport with viewport or full page with full page; label each artifact.
A visual diff reports many changes on a news page	Headlines, timestamps, ads, or other dynamic content changed.	Review the changed regions in context and align page state where practical before deciding whether layout regressed.
Playwright navigation times out waiting for `networkidle`	The page may keep network activity open, so the chosen load condition is not reached.	Use a suitable condition such as `domcontentloaded`, then wait for a page-specific selector or a deliberate short delay before capturing. Keep the rule stable across comparisons.
The screenshot file is missing	The script failed before capture, the URL was not provided, or the output path is different from the current directory.	Set `NEWS_URL`, inspect the script error, and check the path passed to `page.screenshot`.

9. Performance, reliability, and cost

DevTools is convenient for a one-off inspection and has no screenshot API request to configure. Automated Playwright runs add browser setup and execution time, but make the viewport and capture procedure repeatable. Fix the browser version and load-state strategy for comparable runs; dynamic page content remains a source of visual noise.

For local Playwright, cost depends on the environment used to run the browser; the research sources provide no benchmark or price comparison. A screenshot is only reliable evidence of the captured state. It does not establish real-device behavior, page correctness beyond what is visible, or that every asynchronous element has loaded.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request can return a PNG, JPEG, WebP, or PDF. The API parameters used by other screenshot APIs also work, which can make switching straightforward. See the ScreenshotNeo API documentation.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/news"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/news'
});
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);

Set the 360-pixel viewport using the API’s viewport options documented in the API reference. ScreenshotNeo can accept cookie or consent banners like a visitor and remove more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Response headers identify the page verdict and whether the request 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 per month with no card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan. Sign up for 1,000 free screenshots a month, with no card.

FAQ

Does a 360-pixel viewport mean the phone has a 360-pixel physical screen?

No. Specify 360 CSS pixels for the browser layout viewport. Physical screen resolution and DPR are separate settings.

Should I capture the viewport or the whole page?

Use a viewport capture to inspect the current screen and a full-page capture when below-the-fold layout is part of the question. Compare the same mode across runs.

Does a passing screenshot prove the page works on phones?

No. It shows one emulated rendered state. Confirm on a physical phone when hardware, touch, browser chrome, or performance could affect the result.

Is 360 pixels a representative width for Indian phones?

The research for this guide establishes no device-market statistic. Treat 360 CSS pixels as the requested test width, not as a claim about how common a particular phone width is.