How to Test a Responsive Website at 393 by 873 Pixels for Indian Android Phones

To test a responsive website at 393 × 873 pixels, open it in Chrome DevTools, enable Device Mode, choose Responsive, and enter a width of 393 and a height of 873. These are CSS-pixel viewport dimensions. Inspect the page from top to bottom, exercise its important touch interactions, and test nearby sizes if you need confidence around breakpoints.

This is a controlled viewport check, not proof of compatibility with every Indian Android phone. The supplied research does not establish 393 × 873 as a standard or prevalent Indian handset size. DevTools approximates mobile behavior from a desktop; verify on a physical Android phone when browser or hardware behavior matters. [Chrome DevTools: Device Mode]

1. Set Chrome DevTools to 393 × 873

1. Open the target page in desktop Chrome.
2. Open DevTools with F12 or Ctrl+Shift+I on Windows/Linux, or Cmd+Option+I on macOS.
3. Turn on the device toolbar using the phone/tablet icon, or press Ctrl+Shift+M / Cmd+Shift+M.
4. In the device toolbar, select Responsive from the device selector.
5. Set width to 393 and height to 873. Keep the units as CSS pixels; do not multiply either value by device pixel ratio (DPR).
6. Reload the page and inspect both the initial viewport and the entire page by scrolling.

DevTools provides controls for viewport size and DPR separately. A 393 CSS-pixel layout viewport remains 393 CSS pixels when DPR changes; DPR affects how CSS pixels are rasterized into hardware pixels. [Chrome DevTools: Device Mode]

2. Confirm the site is using a mobile viewport

Check the document head for a viewport declaration such as:

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

On mobile pages, Android guidance recommends matching the viewport width to device-width and using flexible media queries. Without a suitable viewport declaration, a page can be laid out against a wider virtual viewport and then scaled down, making a 393-pixel responsive check misleading. [Android Developers: Support different screens in web apps]

Avoid disabling user zoom with user-scalable=no unless there is a compelling accessibility-safe reason; it is not needed to perform this test.

3. Inspect layout, content, and touch behavior

At 393 × 873, work through this checklist:

• Horizontal fit: look for horizontal scrolling, clipped edges, fixed-width containers, and elements extending beyond the viewport.
• Text: check headings, navigation labels, buttons, and long words for overlap, truncation, or awkward wrapping.
• Images and media: check that images fit their containers and remain sharp enough at the emulated DPR. Confirm video and embedded content do not overflow.
• Page structure: scroll from top to bottom and inspect cards, tables, footers, sticky headers, and floating controls.
• Touch flows: open menus, use forms, dismiss dialogs, activate primary calls to action, and test any swipe or expandable control. Check that controls are practical to tap and that overlays do not block them.
• Loading states: reload with the Network panel open and watch for late-loading content that shifts the page or leaves blank regions.

These are practical checks for content fitting a narrow viewport; they are not a published formal checklist specific to 393 × 873.

4. Check dimensions, DPR, and aspect ratio

The viewport is the area the browser makes available to the page. Its CSS-pixel dimensions are not the same as the physical pixel dimensions of a phone display. Android documentation describes viewport width in CSS pixels and explains that screen density changes the relationship between CSS and hardware pixels. [Android Developers: viewport and density]

Setting	What it controls	How to use it
Width and height	Layout viewport in CSS pixels	Enter 393 × 873 exactly for this test.
DPR	Pixel density used when drawing CSS pixels	Adjust separately if testing density-sensitive assets; do not treat one value as representative of Indian phones generally.
Throttling	Approximate CPU or network constraints	Use when checking whether slower rendering or loading changes the experience.
Orientation and sensors	Other simulated device conditions	Useful for orientation-dependent or location-sensitive behavior, but not a substitute for testing on a device.

Do not infer a handset model or market-wide compatibility from this geometry. The title’s dimensions define a useful test case, not a source-backed Indian Android standard.

5. Add nearby viewport checks

A single viewport can miss a breakpoint immediately above or below it. Repeat the same inspection at a slightly narrower and wider width, and at a different aspect ratio if the page has tall-screen interactions. Android responsive design guidance recommends testing varied screen sizes and aspect ratios; it does not establish these particular dimensions as web-browser compatibility targets. [Android Developers: responsive and adaptive design]

For release decisions, write down the exact viewport, DPR, browser, and device conditions tested. Say the page passed at those conditions rather than claiming compatibility with all Android phones.

6. When to test on a real Android phone

Device Mode is useful for quick, repeatable layout checks, but it does not run the page on mobile hardware. Chrome describes it as an approximation and notes that it cannot reproduce all device characteristics. When a bug involves browser differences, performance, keyboard behavior, scrolling, or hardware, open the site on a physical Android phone. Remote debugging can inspect the page running on a connected device. [Chrome DevTools: Device Mode and its limits]

Android Emulator or Firebase Test Lab can extend device coverage when a set of physical phones is not available. The cited Android guidance names these options; verify their current availability and terms before relying on them. [Android Developers: responsive design testing]

Or skip the browser setup

For a screenshot of a page at this viewport, use ScreenshotNeo’s screenshot API. It accepts a URL and can return a screenshot or PDF. See the API documentation for the available parameters and options. Set the viewport dimensions to 393 by 873 in your request:

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

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture. 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. A screenshot is useful for visual review, while real-device testing is still needed to verify actual touch and browser behavior. Learn more at ScreenshotNeo.

Sign up for 1,000 free screenshots a month, with no card required.

Troubleshooting

Symptom	Likely cause	Fix
The page looks like a desktop site shrunk to fit	Missing or unsuitable viewport meta tag	Add or correct width=device-width, initial-scale=1, then reload.
Horizontal scrollbar appears	A fixed-width element, wide image, long unbreakable string, or positioned element exceeds the viewport	Inspect overflowing elements in DevTools; use responsive sizing, wrapping, or a suitable max-width.
Text or controls look too small	Content is scaled due to viewport configuration or CSS sizing	Verify the viewport declaration and inspect computed styles at the target width.
Layout changes when DPR changes	Density-specific CSS or image selection is active	Keep viewport dimensions fixed and test the relevant DPR separately; report both settings.
A menu or form works in emulation but fails on a phone	Emulation does not reproduce every browser, hardware, keyboard, or touch condition	Reproduce on the physical Android device and inspect it with remote debugging.
Content jumps after loading	Late images, fonts, ads, or embedded content change layout	Reserve space for delayed content and retest after network activity settles.

Performance, reliability, and cost

• Fast iteration: DevTools makes it cheap to repeat the exact same viewport after CSS changes. Save the test conditions in your QA notes.
• Coverage limits: 393 × 873 covers one geometry. Nearby widths, different aspect ratios, other browsers, and physical phones cover different failure modes.
• Rendering fidelity: DPR, fonts, network speed, CPU, browser version, and device hardware can affect screenshots or interactions. Simulating selected conditions does not recreate the full phone environment.
• Cost: the DevTools viewport check uses the browser tools already available in Chrome. Emulator or hosted test options may have separate setup and terms; check those before adopting them. ScreenshotNeo has a free tier of 1,000 shots per month without a card and paid plans beginning at $5 for 3,000.
• Screenshot billing: ScreenshotNeo reports whether a request was billed and the page verdict in response headers; its stated policy bills only clean shots, while bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing.

FAQ

Does 393 × 873 identify a specific Indian Android phone?

No. The research does not establish that these dimensions identify a particular or representative handset. Treat them as the requested CSS-pixel test viewport.

Should I enter the physical screen resolution?

No. Enter 393 and 873 as CSS-pixel viewport dimensions. Physical pixels and CSS pixels differ according to screen density.

Does a passing DevTools test prove Android compatibility?

No. It confirms the page at the emulated settings. Test on the target physical device and browser when compatibility confidence matters.

Should I test only this size?

No. Add widths around responsive breakpoints and another aspect ratio for broader layout coverage.