What to Do When Selenium Shows the Wrong Mobile Layout on an Indian Website

If Selenium shows an Indian website’s desktop layout or an unexpected arrangement in a mobile screenshot, check the Chrome session’s mobile emulation settings first. Then verify the effective viewport width and height, device pixel ratio, mobile and touch behavior, and whether you captured the viewport or the full page. Compare at the same dimensions in Chrome DevTools; if emulation still does not match the behavior that matters, validate on an actual phone.

This is a browser configuration and responsive-layout diagnosis, not an India-specific Selenium behavior. The supplied research does not establish that Indian websites have a unique cause or that this problem occurs at a particular rate.

1. Confirm what “wrong layout” means

Before changing code, identify the mismatch you see: desktop navigation instead of a mobile menu, columns that do not stack, text wrapping differently, or a screenshot that cuts off content. Different mismatches point to different variables. A mobile-sized desktop window alone does not necessarily configure Chrome’s mobile behavior.

Keep these comparison settings aligned:

• CSS viewport width and height: responsive breakpoints commonly depend on the viewport width.
• Device pixel ratio: this affects the relationship between CSS pixels and screenshot pixels.
• Mobile rendering and touch behavior: configure them where the page or test depends on mobile behavior.
• Orientation: compare portrait with portrait, or landscape with landscape.
• Capture scope: compare viewport-only images with viewport-only images, or full-page images with full-page images.

Chrome DevTools Device Mode can show responsive dimensions and media-query breakpoints. Chrome describes it as a first-order approximation of a mobile device, so use a real device for final validation when the distinction matters. See Chrome DevTools Device Mode.

2. Configure ChromeDriver for mobile emulation

Set mobile emulation on the Chrome options used to create the WebDriver session. Choose either a supported device preset or explicit device metrics. The exact preset names and options depend on the ChromeDriver and Selenium versions in use; check the current ChromeDriver mobile emulation reference and your binding’s documentation.

JavaScript with Selenium WebDriver

The Selenium JavaScript options API documents configuring a named device. This example uses a device name supported by your installed ChromeDriver version; confirm the name against its current device list.

const { Builder } = require('selenium-webdriver');
const chrome = require('selenium-webdriver/chrome');

async function main() {
  const options = new chrome.Options();
  options.setMobileEmulation('iPhone X');

  const driver = await new Builder()
    .forBrowser('chrome')
    .setChromeOptions(options)
    .build();

  try {
    await driver.get('https://example.com');
    await driver.takeScreenshot().then(image => {
      require('node:fs').writeFileSync('mobile.png', image, 'base64');
    });
  } finally {
    await driver.quit();
  }
}

main().catch(error => {
  console.error(error);
  process.exitCode = 1;
});

Install the binding with npm install selenium-webdriver and make Chrome and a compatible ChromeDriver available. Selenium’s Chrome Options API documents the JavaScript configuration shape. Device preset availability can vary, so if the named device is rejected, use explicit metrics supported by your ChromeDriver version.

Use explicit device metrics when a preset is unsuitable

For a reproducible test, supply the target CSS width, height, and pixel ratio, plus mobile and touch settings when supported. ChromeDriver documents these individual mobile emulation attributes. This example shows the configuration structure; verify the capability names against your installed ChromeDriver documentation.

const { Builder } = require('selenium-webdriver');
const chrome = require('selenium-webdriver/chrome');

async function main() {
  const options = new chrome.Options();
  options.setMobileEmulation({
    deviceMetrics: {
      width: 390,
      height: 844,
      pixelRatio: 3,
      touch: true,
      mobile: true
    },
    userAgent: 'Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Mobile Safari/537.36'
  });

  const driver = await new Builder()
    .forBrowser('chrome')
    .setChromeOptions(options)
    .build();

  try {
    await driver.get('https://example.com');
    const pngBase64 = await driver.takeScreenshot();
    require('node:fs').writeFileSync('mobile.png', pngBase64, 'base64');
  } finally {
    await driver.quit();
  }
}

main().catch(error => {
  console.error(error);
  process.exitCode = 1;
});

The sample user agent is illustrative, not a guarantee of matching any particular phone or current Chrome release. Omit or update it based on the browser behavior you need to test. If you are testing responsive CSS alone, begin with dimensions and pixel ratio; add mobile or touch behavior only when the test requires it. Change one variable at a time when diagnosing a mismatch.

3. Check the effective viewport and responsive breakpoint

After navigation, inspect the rendered page at the target viewport. The browser window’s outer dimensions and the page’s CSS viewport are not always interchangeable, especially when browser chrome is present. Selenium documents window sizing and screenshot operations in its windows and tabs guide. DevTools lets you enter responsive dimensions and inspect which media-query breakpoint is active.

1. Open the same URL in Chrome DevTools Device Mode.
2. Set the same width and height as the Selenium configuration.
3. Check the page at that width and inspect its media-query breakpoints.
4. Compare the result with Selenium before changing other settings.
5. If the layout differs, vary width, pixel ratio, mobile behavior, and touch behavior individually.

If a page switches layout at, for example, a breakpoint near the width you chose, a small width difference can move it to the other side of that breakpoint. Do not assume a device label guarantees the exact viewport you intended; record the dimensions that the test actually uses.

4. Make sure the screenshots cover the same content

Selenium’s screenshot command captures the current browsing context. A viewport screenshot and a full-page screenshot answer different questions, so compare like with like. Chrome DevTools provides viewport and full-size page screenshot options; see its Device Mode documentation.

• For a mobile navigation or above-the-fold layout check, compare viewport captures.
• For page length, content below the fold, or lazy-loaded sections, compare full-page captures.
• Keep scroll position and page state consistent, especially if the page changes on scroll.

A screenshot that is clipped or has a different page height may be a capture-scope mismatch rather than a responsive CSS issue.

5. Troubleshooting checklist

Symptom	Likely cause	What to do
Desktop navigation remains visible in a narrow window	The session only has a small desktop window, or mobile emulation was not applied to the session that loaded the page.	Set mobile emulation in Chrome options before building the driver, then create a fresh session and confirm the target dimensions.
The layout changes at an unexpected width	The effective CSS viewport differs from the assumed width, or the page’s breakpoint is near that width.	Set and inspect the same responsive dimensions in DevTools; check the active media query.
Layout looks right but tap-oriented controls behave differently	Touch behavior is not configured, or the page requires a real device interaction.	Enable touch in supported mobile metrics and test the interaction. Validate on hardware if the real-phone behavior matters.
Screenshot dimensions look unexpectedly large or small	Device pixel ratio differs, or the comparison tool reports physical image pixels while the page uses CSS pixels.	Match pixel ratio and viewport settings; distinguish CSS dimensions from output image dimensions.
Bottom of the page is missing	The capture is viewport-only, or content has not loaded below the fold.	Use a full-page capture for the comparison and check the page’s scroll or lazy-load behavior.
ChromeDriver rejects a device name or mobile option	The preset or capability is unsupported by that ChromeDriver version, or the Selenium binding’s API differs.	Check the current ChromeDriver mobile emulation reference and Selenium API for the installed versions; use supported explicit metrics if appropriate.
Results differ between runs	The browser session, dimensions, page state, or capture timing differs.	Record browser and driver versions, recreate the session with the same options, use the same URL and state, and compare one setting at a time.

Record Chrome and ChromeDriver versions when reproducing a failure. Compatibility and supported options can change, so consult the current ChromeDriver documentation and Selenium options API for the versions you run.

6. Know when emulation is not enough

Desktop emulation is useful for repeatable responsive checks, but it remains an approximation of a phone. If the discrepancy concerns real-device browser behavior, touch input, or the rendered result on a specific phone, test on an actual mobile device. Chrome’s guidance recommends real-device testing when emulation does not answer the question. An existing Android phone may be enough for a spot check; buying hardware is not automatically necessary. For remote browser execution across a team, Selenium Grid is the Selenium option documented for distributing sessions: Selenium Grid.

7. Performance, reliability, and cost

Emulation settings do not by themselves guarantee consistent screenshots. For reliable comparisons, pin the browser and driver versions used by the test environment, configure emulation before session creation, use a stable URL and page state, and keep dimensions and capture scope identical. Record the settings alongside the image so a future run can reproduce them.

The cited Selenium, ChromeDriver, and DevTools documentation describes browser configuration and capture; it does not establish a universal runtime or cost for this workflow. Local runs use the browser resources on the machine executing them. Remote execution adds the infrastructure your team operates or chooses to use. Test only as many dimensions and device configurations as your coverage requires, then use real hardware for the specific cases where emulation is insufficient.

8. Or skip the browser setup

If you need a website screenshot without configuring ChromeDriver, ScreenshotNeo is a website screenshot API and MCP server. One GET request accepts a URL and returns an image or PDF; it can also capture a chosen viewport or full page and offers device presets and custom viewport settings. The API supports options including CSS selectors, dark mode, custom CSS and JavaScript, waits, cookies and headers. See the ScreenshotNeo API documentation for parameters and current usage details.

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

import requests

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

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`ScreenshotNeo returned HTTP ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and whether the request was billed. Its MCP server exposes take_screenshot, get_page_info, and capture_pdf to Claude, Cursor, and other MCP clients. The free plan includes 1,000 shots a month with no card; paid plans start at $5 for 3,000 shots. Every feature is on every plan. These capabilities make it useful when your goal is to obtain a cleaned screenshot quickly; Selenium remains the way to control and inspect the browser session described above.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

9. FAQ

Is the problem specific to Indian websites?

The documented checks apply to responsive pages generally. The available research does not establish a cause unique to Indian websites.

Should I use a named device or custom dimensions?

Use a supported preset when you want its documented device configuration. Use explicit metrics when you need to make width, height, and pixel ratio easy to reproduce.

Does a mobile screenshot prove the page works on a phone?

No. Emulation is an approximation. Confirm on a real device when the exact phone behavior is important.

Do I have to buy an Android phone to validate the result?

No. If a suitable phone is already available, it can be used for optional validation. The sources do not say that purchasing one is necessary.