How to Check a Mobile Website Layout at 360 Pixel Width for Indian Users

To check a mobile website at 360 pixels wide, open it in Chrome DevTools, switch on the Device Toolbar, choose Responsive, and set the width to 360. This is 360 CSS pixels, not necessarily 360 physical screen pixels. Check the viewport meta tag, inspect the page and its important states, and use real-device testing if touch, performance, or browser behavior matters.

A 360-pixel test is a specific viewport condition, not evidence that every Indian user has a 360-pixel-wide phone. Use your site analytics or representative user research to select additional widths and devices for your audience.

1. Set a 360 CSS-pixel viewport in Chrome DevTools

Open the website in Chrome.
Open DevTools. Use Ctrl+Shift+I on Windows or Linux, or Command+Option+I on macOS.
Toggle the Device Toolbar with Ctrl+Shift+M on Windows or Linux, or Command+Shift+M on macOS. You can also use the device toolbar button in DevTools.
In the device controls, select Responsive and enter 360 for the width. Set a height that shows the content or interaction you want to inspect.
Reload the page if it does not respond to the viewport change, then inspect it at the entered width.

Chrome’s Responsive mode accepts manually entered dimensions. The width is the key condition for this check; choose the height based on what you need to see. See Chrome’s guide to simulating mobile devices with Device Mode.

2. Confirm the page uses a mobile viewport

In the page source or DOM, look for a declaration such as:

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

width=device-width tells the browser to use the device’s width as the layout viewport. Without suitable viewport metadata, a mobile browser may lay out a page at a wider, desktop-like width and scale it down, making the page appear tiny rather than reflowing. Review Android’s guidance on screen support in web apps and Chrome’s Lighthouse viewport guidance.

DevTools can show the page as it currently renders, but inspect the HTML or DOM to determine whether the declaration is present and correct. If it is missing, add the viewport metadata to the document head and retest.

3. Inspect layout and interaction at 360 pixels

Scroll through the whole page and exercise its important states. Look for concrete layout failures:

Horizontal scrolling: the page or a component extends beyond the viewport. Identify the overflowing element rather than hiding overflow on the whole page, which can conceal content.
Clipped or overlapping content: headings, navigation, cards, images, and dialogs collide or are cut off.
Text that appears scaled down: check whether the viewport is configured correctly and whether fixed-width content is forcing the page to shrink.
Forms and controls that are hard to use: labels wrap badly, fields are clipped, buttons are crowded, or menus cannot be reached.
Images and embedded content: check that they fit their containers and that important content is not hidden outside the viewport.
Interactive states: open navigation menus, dialogs, validation messages, and other states that could change the layout.

These are practical checks for the rendered page. The viewport and breakpoint tools help you reproduce the condition; they do not automatically determine whether a particular design is usable.

4. Find the active responsive breakpoint

Open the Device Toolbar options and enable Show media queries. Inspect the media-query markers to see the CSS breakpoint ranges and determine which rules are active at 360 pixels. If a layout change happens near the tested width, check just below and just above that breakpoint as well. This can reveal a transition that fails even though the page looks acceptable at exactly 360 pixels.

For example, if a navigation bar changes at a breakpoint near the current viewport, inspect both sides of that threshold and test the menu interaction in each layout. Use the breakpoints defined by the site’s CSS; do not assume one set of widths fits every project.

5. Understand CSS pixels, DPR, height, and orientation

The 360 value in Responsive mode is a CSS-pixel viewport width. Device pixel ratio (DPR) describes how CSS pixels map to physical display pixels. A high-density display can use multiple physical pixels to draw one CSS pixel, so DPR and viewport width are separate test settings. Android explains this relationship in its screen support guidance.

For a basic narrow-layout check, set the width to 360 and use a convenient height. If the page depends on screen orientation or viewport height, also test landscape or another relevant height. Adjust DPR when image sharpness, canvas rendering, or other density-sensitive graphics are part of the issue; changing DPR does not substitute for changing CSS viewport width.

6. Decide whether emulation is enough

Device Mode is an approximation of a mobile device. It is useful for checking responsive layout, but the desktop computer does not have the same mobile CPU or all of the same device behavior. For a defect involving touch, browser-specific behavior, performance, or a particular phone, validate on real hardware too. Chrome recommends real-device testing when higher fidelity is needed and offers CPU and network throttling for a more demanding initial emulation pass. See Chrome Device Mode documentation.

Use emulation to reproduce a viewport and inspect responsive CSS quickly.
Use CPU or network throttling when you need to see how the page behaves under constrained conditions.
Use a real phone when the issue depends on touch, a specific browser or device, or actual mobile performance.

7. Choose additional tests for your Indian audience

The sources cited here explain viewport configuration and device emulation; they do not establish a current India-specific distribution of handset widths, browsers, operating systems, or DPR. Treat 360 pixels as the explicit condition requested here, not as a claim about the most common Indian phone.

To plan broader coverage, review your own audience analytics or representative user research. Then test relevant viewport widths around your CSS breakpoints, portrait and landscape layouts where applicable, and real devices or browsers that your audience uses. This is an audience-specific testing recommendation, not a market statistic.

8. Capture a repeatable screenshot for review

A screenshot can help compare the same page state across viewport widths or share a layout issue with teammates. To make captures useful, keep the URL, viewport dimensions, and page state consistent. A screenshot documents what rendered; interactive or device-specific defects may still need direct testing.

For a browser-based capture, set the viewport to 360 CSS pixels as described above and capture the page after it has reached the state you want to review. If you need a repeatable capture in a workflow, an API can return an image from a URL without requiring you to run a browser yourself.

Or skip the browser setup

With ScreenshotNeo, one GET request captures a URL as an image or PDF. The API can capture at a chosen viewport and supports full-page capture, device presets, and other options; see the ScreenshotNeo API documentation.

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

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

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Replace the example URL with the page you want to capture and provide your API key. Add the documented viewport parameters to request a 360-pixel-wide capture. 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, and the free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card required.

Troubleshooting

What you see	Likely cause	What to do
The page still looks like a desktop page, only smaller	The viewport meta tag may be missing or incorrect, or fixed-width content may be forcing a wide layout.	Check the document head for `width=device-width, initial-scale=1`. Inspect wide elements and the active media queries.
Content extends past the right edge	A fixed-width element, long unbroken string, image, or embedded component exceeds the viewport.	Inspect the overflowing element at 360 pixels and adjust its sizing or wrapping behavior. Retest the page and the component.
The layout changes unexpectedly near 360	A media query breakpoint is active near the test width.	Show media queries and compare widths immediately below and above the breakpoint.
The emulated layout looks right, but a phone behaves differently	Device Mode is an approximation and does not reproduce every real-device condition.	Reproduce the issue on the relevant phone and browser, especially for touch, performance, or device-specific behavior.
Text or graphics look different at another density	DPR differs; DPR affects physical pixel mapping, not the CSS viewport width.	Keep the viewport width at 360 CSS pixels and adjust DPR separately if display density is relevant.
A screenshot capture is blank or misses the expected state	The page may not have finished loading, or the desired content may depend on interaction or a particular page state.	Wait for the page or content to appear, reproduce the required interaction, and capture the intended state. For API options, consult the provider’s documentation.

Performance, reliability, and cost

Chrome DevTools is sufficient for manually checking a responsive layout and does not require a screenshot service. Throttling CPU or network can make an emulation pass more demanding, but it does not turn a desktop into a real phone. Add physical-device validation when the behavior under test depends on actual hardware or browser conditions.

For repeated captures, keep the URL, viewport, and page state consistent so reviewers can compare results. Consider whether the page needs time to load or an interaction before capture. A returned image cannot prove that controls work or that a layout is usable; combine it with direct interaction checks.

ScreenshotNeo offers a free tier of 1,000 shots per month with no card. Paid plans are Starter at $5 for 3,000, Growth at $15 for 15,000, Pro at $39 for 60,000, Scale at $99 for 250,000, and Business at $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan. Only clean shots are billed; responses include page-verdict and billed headers. Review the documentation for request options and response details.

FAQ

Does 360 pixels mean the phone’s physical screen is 360 pixels wide?

No. In this workflow, 360 is the CSS-pixel viewport width. DPR separately describes how CSS pixels map to physical pixels.

Does testing at 360 pixels prove the page works for Indian users?

No. It verifies behavior under that viewport condition. Choose additional widths and devices using your own audience analytics or user research.

Can DevTools replace testing on a phone?

It is useful for responsive layout checks, but not a complete substitute when touch, real mobile performance, or device-specific behavior matters.

Do I need a paid tool to check a 360-pixel layout?

No. Chrome DevTools lets you enter a custom viewport. A capture API is optional for repeatable image capture or automated workflows.