How to Test a Mobile Web Page at Redmi Note 13 Resolution with Selenium

To test a page for a Redmi Note 13 with Selenium, configure ChromeDriver’s mobile emulation with the CSS viewport width, CSS viewport height, and device-pixel ratio measured on the target phone and browser. Do not enter the phone’s 2400 × 1080 physical display resolution as the CSS viewport. Xiaomi gives 2400 × 1080 as the display resolution for the standard global Redmi Note 13; physical pixels and CSS layout pixels are different measurements.

This guide targets the standard global Redmi Note 13, not the Redmi Note 13 5G, Pro, or Pro+ models. The exact CSS viewport can depend on the browser, orientation, and software configuration, so measure the intended setup. Xiaomi lists a 6.67-inch display and 395 PPI in its [official Redmi Note 13 specifications](https://www.mi.com/global/product/redmi-note-13/specs/) and [support FAQ](https://www.mi.com/global/support/faq/details/KA-90002/). Chrome defines device pixel ratio as the ratio of physical screen pixels to CSS pixels ([Chrome device emulation concepts](https://developer.chrome.com/docs/devtools/device-mode/)).

1. Measure the target phone’s CSS viewport

Open the page on the Redmi Note 13 in the Android browser you intend to support. Read the following values from the page’s JavaScript console or log them temporarily from the page:

({
  innerWidth: window.innerWidth,
  innerHeight: window.innerHeight,
  devicePixelRatio: window.devicePixelRatio,
  screenWidth: window.screen.width,
  screenHeight: window.screen.height
})

Record the browser and version, phone variant, orientation, and software context alongside the values. Repeat in portrait and landscape if both matter. Use the measured innerWidth, innerHeight, and devicePixelRatio for the Selenium profile. The physical 2400 × 1080 specification alone does not establish those CSS values. Android’s web guidance recommends a viewport declaration such as width=device-width for pages designed for mobile screens ([Android viewport guidance](https://developer.android.com/develop/ui/views/layout/webapps/targeting)).

2. Configure Selenium and ChromeDriver

ChromeDriver’s custom mobile emulation accepts device metrics including width, height, and pixel ratio. The following Java example follows the documented map-based configuration. Replace the example constants with measurements from the intended Redmi Note 13 and browser. It is an implementation example; the values are deliberately not presented as universal phone settings.

import java.util.HashMap;
import java.util.Map;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

public class RedmiNote13Emulation {
  public static void main(String[] args) {
    // Replace these placeholders with measurements from the target phone.
    int measuredCssWidth = 360;
    int measuredCssHeight = 800;
    double measuredDevicePixelRatio = 3.0;

    Map<String, Object> deviceMetrics = new HashMap<>();
    deviceMetrics.put("width", measuredCssWidth);
    deviceMetrics.put("height", measuredCssHeight);
    deviceMetrics.put("pixelRatio", measuredDevicePixelRatio);
    deviceMetrics.put("touch", true);
    deviceMetrics.put("mobile", true);

    Map<String, Object> mobileEmulation = new HashMap<>();
    mobileEmulation.put("deviceMetrics", deviceMetrics);

    ChromeOptions options = new ChromeOptions();
    options.setExperimentalOption("mobileEmulation", mobileEmulation);

    WebDriver driver = new ChromeDriver(options);
    try {
      driver.get("https://example.com");
      System.out.println("Loaded: " + driver.getTitle());
    } finally {
      driver.quit();
    }
  }
}

The numeric values above are placeholders that make the example structurally complete; they are not asserted Redmi Note 13 CSS dimensions or a recommended DPR. Use a Selenium Java dependency and a compatible ChromeDriver/Chrome installation in your project. Check the current [ChromeDriver mobile emulation documentation](https://developer.chrome.com/docs/chromedriver/mobile-emulation/) for syntax and compatibility with your installed versions. It documents mobileEmulation, deviceMetrics, and configuring individual device attributes. If your ChromeDriver supports a named device profile, that is another option; custom measured metrics make the target configuration explicit.

Python alternative

For a Python Selenium suite, pass the same Chromium option through Chrome’s experimental options:

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

# Replace with measurements from the target phone and browser.
measured_css_width = 360
measured_css_height = 800
measured_device_pixel_ratio = 3.0

options = Options()
options.add_experimental_option("mobileEmulation", {
    "deviceMetrics": {
        "width": measured_css_width,
        "height": measured_css_height,
        "pixelRatio": measured_device_pixel_ratio,
        "touch": True,
        "mobile": True,
    }
})

driver = webdriver.Chrome(options=options)
try:
    driver.get("https://example.com")
    print("Loaded:", driver.title)
finally:
    driver.quit()

Install Selenium in the project environment and use a compatible Chrome/ChromeDriver setup. Keep the device-metric values sourced from your own measurement, not copied from the placeholders.

Node.js alternative

With Selenium WebDriver for JavaScript, set the Chrome mobile-emulation capability. This example uses the Selenium JavaScript package’s Chrome options API:

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

// Replace with measurements from the target phone and browser.
const measuredCssWidth = 360;
const measuredCssHeight = 800;
const measuredDevicePixelRatio = 3.0;

(async () => {
  const options = new chrome.Options().setMobileEmulation({
    deviceMetrics: {
      width: measuredCssWidth,
      height: measuredCssHeight,
      pixelRatio: measuredDevicePixelRatio,
      touch: true,
      mobile: true,
    },
  });

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

  try {
    await driver.get('https://example.com');
    console.log('Loaded:', await driver.getTitle());
  } finally {
    await driver.quit();
  }
})();

Confirm the option method against the Selenium JavaScript and ChromeDriver versions pinned by your project. The emulation capability and supported settings come from ChromeDriver; wrapper APIs can vary by Selenium release.

3. Assert the emulated viewport and check the page

After navigation, read the viewport values from the browser. This catches a profile that was ignored, misconfigured, or altered by a browser or driver mismatch.

import org.openqa.selenium.JavascriptExecutor;
import java.util.Map;

@SuppressWarnings("unchecked")
Map<String, Object> viewport = (Map<String, Object>) ((JavascriptExecutor) driver)
    .executeScript("return { width: window.innerWidth, height: window.innerHeight, dpr: window.devicePixelRatio }");

System.out.println(viewport);
// Compare width, height, and dpr with the measured target profile.

Use explicit assertions in your test framework. Then check the behavior that matters to your page:

• Horizontal overflow: compare document width with the viewport width and investigate unexpected overflow.
• Mobile navigation: verify the menu opens, closes, and exposes the expected links at the target width.
• Critical content and controls: confirm they are visible and usable without clipping or overlap.
• Responsive breakpoints: test widths just below and above the breakpoints used by your CSS, not only the phone profile.
• Touch flows: verify important interactions using touch-capable automation where your test setup supports it.
• Orientation: configure and assert portrait and landscape dimensions separately when both are in scope.

These are recommended checks, not results from a test run. Chrome DevTools can help inspect responsive breakpoints, but device mode is a simulation. Chrome describes it as a “first-order approximation” and notes it does not actually run the code on a mobile device ([Chrome DevTools device mode](https://developer.chrome.com/docs/devtools/device-mode/)).

4. Understand what Selenium emulation proves

A desktop Chrome session configured with mobile metrics is useful for repeatable responsive-layout coverage in a local run or CI. It lets you hold viewport dimensions and device scale steady and exercise mobile-specific layout branches. It does not prove that the page behaves identically on a physical Redmi Note 13.

Test mode	Useful for	Limit
Selenium with ChromeDriver mobile emulation	Repeatable layout and breakpoint checks; automated regression coverage	Simulated device metrics and browser behavior; not the handset’s real hardware or complete environment
Actual Redmi Note 13 browser	Checking touch behavior, browser integration, and device-specific performance	Requires access to the exact phone and browser configuration

For touch-sensitive, browser-specific, performance-sensitive, or otherwise critical behavior, validate on the actual handset when available. Describe desktop automation precisely, for example: “Tested with Chrome mobile emulation configured to the measured Redmi Note 13 viewport.” Do not label it as a physical-device test.

Or skip the browser setup

If your immediate goal is a page screenshot rather than an automated Selenium interaction test, ScreenshotNeo is a website screenshot API and MCP server. Its API accepts a URL and returns an image or PDF. Here is the one-call pattern for a screenshot; see the ScreenshotNeo API documentation for parameters and usage.

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 your page. ScreenshotNeo accepts cookie and consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses report page verdict and billing status in headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf for AI agents and MCP clients. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Screenshot capture can help review a rendered page, but it does not replace Selenium interaction tests or actual-phone validation.

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

Troubleshooting

Symptom	Likely cause	What to do
The browser reports a viewport much wider than expected	Physical panel pixels were entered as CSS width, or mobile emulation was not applied	Use measured CSS dimensions; read window.innerWidth and window.devicePixelRatio after navigation.
The layout differs from the target phone despite matching width	DPR, browser version, orientation, or software context differs	Record and align those values; verify the same CSS viewport and DPR on the phone.
ChromeDriver rejects the mobile-emulation capability	Capability shape or API differs for the installed driver or Selenium binding	Check the current ChromeDriver mobile emulation documentation and the binding’s API; update or align compatible versions.
Driver starts but behaves like a desktop browser	The capability key or nested deviceMetrics map is malformed, or only viewport size was set	Inspect the emitted capability; include mobile, touch, and the documented metrics as appropriate, then assert runtime values.
Screenshot dimensions look much larger than the CSS viewport	DPR scales raster pixels relative to CSS pixels	Compare CSS dimensions and DPR separately; do not infer the layout viewport from screenshot bitmap dimensions alone.
A menu or gesture works in emulation but not on the phone	Simulation does not reproduce every touch or browser integration detail	Reproduce on the actual device and browser; retain the Selenium check for repeatable layout coverage.
Only one orientation passes	The test profile covers only one set of dimensions	Measure and configure landscape as a separate profile and assert its viewport independently.

Performance, reliability, and cost

Mobile emulation changes browser metrics and behavior; it does not make a desktop machine’s CPU, memory, network, or graphics performance equivalent to the Redmi Note 13. Treat timing results from emulation as results for the machine and test environment that ran them. Use the handset to assess device performance where it matters.

For reliable CI coverage, keep the measured profile in a named test configuration, record the browser and driver versions, assert the runtime viewport, and run the same checks around important CSS breakpoints. A single profile cannot cover every browser, orientation, or responsive width. Selenium’s infrastructure and any physical-device access have costs determined by your own setup; no universal cost or benchmark follows from the device specifications in this guide.

FAQ

Should I set the Selenium viewport to 2400 × 1080?

No. That is the standard model’s physical display resolution. Measure and configure CSS viewport dimensions and DPR for the target browser.

Are all Redmi Note 13 models interchangeable for this test?

No. This guide refers to the standard global Redmi Note 13. Confirm the exact variant and measure the browser setup you intend to support.

Does a passing Selenium test mean the page works on the phone?

It supports the specific emulated checks you ran. Validate critical real-device behavior on the handset.

Can I use this setup for visual regression testing?

Yes, it can provide repeatable viewport-based captures in your Selenium workflow. Keep browser and driver versions stable and treat differences in raster output separately from CSS layout changes.