How to Capture a Website at Common Android Phone Screen Sizes in India
Capture repeatable Android-sized website screenshots with Chrome DevTools, then validate on real devices. Learn how to choose and record viewport sizes without guessing which are common in India.
To capture a website at an Android-sized screen in India, use Chrome DevTools Device Mode to set a specific CSS viewport, then capture either the visible viewport or the full page. Record the width, height, device pixel ratio (DPR), and capture type so the screenshot can be reproduced. There is no India-specific “most common Android size” established by the available sources, so use your own audience analytics or clearly label a chosen test matrix as a range rather than a market ranking.
Device Mode is useful for quick responsive checks. It is an approximation, not a substitute for checking real Android hardware when browser, touch, or device-specific behavior matters. [Chrome Device Mode documentation]
1. Choose viewport sizes you can explain
A responsive page usually adapts to its CSS viewport width. That width is not necessarily the same as the number of physical pixels in the saved image: DPR describes how device pixels map to CSS pixels. Chrome Device Mode exposes resolution and DPR. Record both the configured viewport and DPR whenever image dimensions matter.
For an India-focused site, start with first-party analytics if available: inspect real mobile viewport widths, group nearby values into a manageable set, and include the widths around your own CSS breakpoints. If analytics are unavailable, choose a deliberate test range and say that it is a test matrix, not a claim about the most common Indian phones. Also test portrait and landscape if those states matter to the page.
| Test case | What to record | Why |
|---|---|---|
| Portrait viewport | CSS width × height, DPR | Checks the narrow layout and image scaling. |
| Landscape viewport | CSS width × height, DPR | Checks navigation, horizontal layout, and short viewport height. |
| Breakpoint neighbors | Widths just below and above each relevant CSS breakpoint | Finds layout transitions and overflow near breakpoints. |
| Full-page capture | Viewport settings plus “full size” capture | Includes content below the fold; useful for checking long pages. |
Android guidance recommends testing varied screen sizes and aspect ratios. Android Emulator can emulate a broad range of sizes, and Firebase Test Lab is another route to device access. [Android responsive and adaptive design guidance]
2. Capture a mobile viewport with Chrome DevTools
- Open the target page in desktop Chrome.
- Open DevTools and turn on Device Mode with the device toolbar control.
- Choose a device preset or select Responsive and enter the CSS viewport width and height you want to test.
- Set or note DPR when it is available. Rotate the viewport or enter landscape dimensions for a landscape case.
- Reload the page if needed. Wait for important images and dynamic content to appear; check that the page uses its mobile layout rather than showing a scaled-down desktop layout.
- Open the Device Mode options menu. Choose Capture screenshot for the current viewport, or Capture a full size screenshot for the full page.
- Name or document the file with the URL and capture settings, for example
product-page-390x844-dpr3-full-page.png. Treat that as a descriptive filename, not proof of a particular handset.
Chrome documents both viewport and full-size screenshot capture in Device Mode. [Chrome Device Mode documentation]
Viewport capture versus full-page capture
A viewport capture saves only the portion currently visible in the emulated viewport. A full-size capture includes page content below the fold. Full-page output can be much taller than the viewport, so check that lazy-loaded images and content have appeared before capturing. If the page loads content only after scrolling or interaction, trigger that behavior first and confirm the result visually.
Keep captures reproducible
- Record the page URL and the date or build under review.
- Record CSS viewport width and height, DPR, orientation, and whether the capture is viewport-only or full-page.
- Keep browser zoom at its normal setting and note any non-default emulation settings.
- Use the same content state, consent choice, and login state when comparing screenshots.
- Capture widths around breakpoints, not just one narrow and one wide size.
3. Check the site’s responsive setup
If the mobile screenshot looks like a tiny desktop page, inspect the page’s viewport declaration before blaming the emulated dimensions. Android’s web app guidance recommends a device-width viewport and responsive CSS media queries. Android browsers may otherwise use a large default viewport. [Android guidance on viewports in web apps]
<meta name="viewport" content="width=device-width, initial-scale=1">Then check the relevant responsive rules and look for fixed-width containers, images wider than their parent, or elements that force horizontal scrolling. A screenshot is a useful symptom, but inspect the page at the exact recorded width to identify which rule causes the layout.
4. Decide when emulation is enough
| Method | Good for | Limit |
|---|---|---|
| Chrome DevTools Device Mode | Fast, repeatable viewport checks and screenshots across chosen dimensions. | Simulates a mobile viewport from desktop; it does not run the page on a phone or reproduce every mobile characteristic. |
| Android Emulator | Trying many Android screen sizes and configurations without owning a separate handset for each. | Still an emulated environment; device-specific behavior may differ. |
| Physical Android phone | Validating actual browser, hardware, touch, and device-specific behavior. | Requires access to the target device or devices. |
| Firebase Test Lab | Remote access to devices when the desired physical devices are not available locally. | Requires setting up and running a device test workflow. |
Use DevTools for early layout work and repeatable screenshots. Validate important findings on an actual Android phone or remote device when hardware or browser behavior is relevant. Chrome describes Device Mode as a first-order approximation and cautions that it cannot simulate every mobile-device characteristic. [Chrome Device Mode documentation] Android also recommends broad size testing and identifies Emulator and Firebase Test Lab as device-access options. [Android responsive and adaptive design guidance]
If you need a screenshot directly from an Android phone, use the device’s screenshot controls. The button combination and steps can differ across phone models; Android Help provides general instructions. [Android Help: take a screenshot]
5. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Send a URL to capture a page as an image or PDF. Use the viewport parameters in the ScreenshotNeo docs to set the dimensions for your chosen Android-sized layout, then save the response as an image.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport 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}`);ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture; each cleanup 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 includes screenshot, page-info, and PDF tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Plans include the same features. See the documentation for available capture settings and parameters.
Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.
6. Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| The page looks like a miniature desktop site. | The site may lack a device-width viewport declaration or responsive rules. | Check for width=device-width in the viewport meta tag and review CSS at the recorded viewport width. |
| The screenshot is the wrong size. | You may be comparing physical image pixels with CSS viewport pixels, or DPR differs. | Record CSS width and height separately from output image dimensions, and note DPR. |
| Content is missing below the fold. | You captured only the visible viewport, or lazy content has not loaded. | Choose full-size capture; wait for assets, scroll or interact to trigger lazy content, then capture again. |
| The screenshot catches a loading state. | Fonts, images, API-driven content, or animations were still changing. | Wait for the page’s important content to settle and repeat the capture under the same conditions. |
| A real phone does not match Device Mode. | Emulation does not reproduce every browser, hardware, or device behavior. | Reproduce on the target phone or use a remote device workflow for device-specific issues. |
| A horizontal scrollbar appears. | A fixed-width element, oversized image, or long unbreakable content exceeds the viewport. | Inspect the page at the exact CSS width and identify the element extending beyond the viewport. |
7. Performance, reliability, and cost
DevTools screenshots have no per-capture API charge, though they take manual browser time and depend on having Chrome available. A small, recorded matrix makes manual comparison more efficient than repeatedly choosing sizes ad hoc. Full-page captures may take longer and produce large files, especially on long pages; make sure the page has finished loading before saving.
Emulation is repeatable for layout checks when dimensions and page state are held constant, but it cannot guarantee handset fidelity. Use real-device validation where the difference could affect users. Do not infer India-wide device prevalence from a handful of selected widths.
For repeated or automated URL captures, ScreenshotNeo offers API and MCP workflows, configurable caching, and bulk capture for up to 100 URLs per call. Its listed plans are Free: 1,000 shots/month; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; Business: $249 for 1,000,000. Yearly billing gives two months free. Only clean shots are billed; failed loads and cache hits are not billed. Use the response’s verdict and billing headers to distinguish outcomes.
FAQ
Which Android screen size is most common in India?
The sources available for this guide do not establish an India-specific ranking. Use your site analytics or document a chosen range as a test matrix.
Can Chrome save a full-page mobile screenshot?
Yes. In Device Mode, choose “Capture a full size screenshot” from the options menu. “Capture screenshot” saves the current viewport.
Does changing DPR change the responsive layout?
Responsive CSS generally follows CSS viewport width. DPR affects the mapping between CSS and physical pixels, so record it when the output image’s pixel dimensions matter.
Do I need to own an Android phone?
No for basic responsive layout checks. DevTools and Android Emulator cover many software-based checks. Use a physical or remote device when actual handset behavior matters.
