DPI and Screen Resolution: A Complete Guide for Testing

What Is Screen Resolution?

Screen resolution is the number of pixels a display can address, written as horizontal count by vertical count. A 1920x1080 panel carries 1920 pixels across and 1080 down, and multiplying the two gives just over two million addressable points.

Resolution on its own says nothing about physical size. The same 1920x1080 grid can stretch across a 32 inch monitor or compress into a 13 inch laptop, and the pixels in the laptop are far smaller. That is the first place the word pixel starts doing two jobs at once.

For testing purposes, treat resolution as a property of the hardware. It sets the ceiling on how much detail a screen can show, and it is the number that marketing names like Full HD and 4K describe. If you need the specific figures that dominate current traffic, our reference on common screen sizes and resolutions tracks them by device class.

What Is DPI?

DPI stands for dots per inch. It originated in printing, where it counts how many individual ink dots a printer lays down along one inch of paper, and a higher figure means finer detail in the printed output.

Screens do not print dots, so the accurate term for a display is PPI, or pixels per inch. The distinction matters in a print workflow and blurs almost everywhere else, because the software you test against kept the older label.

Android is the clearest example. Its documentation defines a density independent pixel against a screen measured in dpi, stating that one dp is a virtual pixel unit that is roughly equal to one pixel on a medium density screen at 160 dpi, per the Android guide to supporting different pixel densities. When an API label says dpi, check which quantity it measures before converting, because Android's figure counts screen pixels rather than ink dots.

DPI vs PPI vs Screen Resolution

Resolution counts pixels, density describes their spacing, and the CSS pixel is an abstraction layered on top of both.

The CSS Reference Pixel

The unit your stylesheet writes is not a hardware pixel. The W3C CSS Values and Units Module Level 4 defines the reference pixel as the visual angle of one pixel on a device with a device pixel density of 96dpi and a distance from the reader of an arm's length.

Because the definition is an angle rather than a length, its physical size scales with viewing distance. The same specification notes that a reading distance of 71 cm gives a reference pixel of 0.26 mm, while a distance of 3.5 m gives one of 1.3 mm. A billboard pixel and a phone pixel can both be correct.

From that anchor, CSS fixes its absolute units against each other: 1in equals 96px, so one CSS pixel is 1/96th of an inch. The specification is candid about why the ratio was frozen there, noting that the change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption broke the content.

The practical consequence is that 96 is a definitional constant, not a measurement of anyone's monitor. Any test that treats a CSS pixel as a hardware pixel is testing an assumption the specification explicitly abandoned.

How Density Reaches Your Code

Every platform exposes density as a multiplier rather than a raw inch measurement. The browser calls it device pixel ratio, Android exposes it as DisplayMetrics.density and groups devices into named density buckets, and Apple calls it a scale factor, but all three answer the same question: how many physical pixels are spent drawing one logical unit.

In the browser, MDN documents window.devicePixelRatio as returning the ratio of the resolution in physical pixels to the resolution in CSS pixels for the current display device. MDN adds that a value of 1 indicates a classic 96 DPI display, while a value of 2 is expected for HiDPI and Retina displays.

Treat it as a float that can change mid session, because dragging a window between a laptop screen and an external monitor changes the display it reports on. For the browser support detail and the edge cases where the value misleads, see our reference on devicePixelRatio browser support and limits.

Measuring Density in a Real Test Run

The values below were read from a running browser rather than derived. They come from a Playwright session on TestMu AI cloud browsers on 6 August 2026, recorded under build 99971055, where window.screen matched the requested 1280x720 viewport.

Both desktop cloud browsers reported a device pixel ratio of exactly 1:

Chrome  / Windows 11   DPR=1  cssViewport=1280x720  screen=1280x720  physical=1280x720
Edge    / Windows 11   DPR=1  cssViewport=1280x720  screen=1280x720  physical=1280x720

A standard desktop grid session runs at 1x. No amount of resizing that window produces a 2x or 3x code path, so a responsive check performed only that way never exercises density at all.

Density has to be requested explicitly. Page zoom is the one exception, since Chromium multiplies the device pixel ratio by the zoom level, but zoom is no substitute because it rescales the CSS viewport at the same time. In Playwright, density is a browser context option set alongside the viewport:

// Emulate a 3x phone screen on a TestMu AI cloud browser
import { Browser } from "@testmuai/browser-cloud";

const client = new Browser();
const session = await client.sessions.create({
  adapter: "playwright",
  lambdatestOptions: {
    browserName: "Chrome",
    browserVersion: "latest",
    "LT:Options": {
      username: process.env.LT_USERNAME,
      accessKey: process.env.LT_ACCESS_KEY,
      platform: "Windows 11",
      build: "Density check",
    },
  },
});

const { browser } = await client.playwright.connect(session);

const context = await browser.newContext({
  viewport: { width: 393, height: 852 },
  deviceScaleFactor: 3,
  isMobile: true,
  hasTouch: true,
});

const page = await context.newPage();
await page.goto("https://www.testmuai.com/selenium-playground/");

const metrics = await page.evaluate(() => ({
  dpr: window.devicePixelRatio,
  cssWidth: window.innerWidth,
  matches3x: window.matchMedia("(min-resolution: 3dppx)").matches,
}));

console.log(metrics);

Run against the same cloud session, that context reported a different set of values from the default one:

BASELINE  DPR=1  css=1280  min-resolution:2dppx=false  3dppx=false
OVERRIDE  DPR=3  css=393   min-resolution:2dppx=true   3dppx=true

Two details in that output matter. The resolution media queries stayed false at 1x and flipped to true at 3x, which means any CSS breakpoint written with a min-resolution query is dead code in a default desktop run.

The second detail is the arithmetic: 393 CSS pixels at a ratio of 3 occupy 1179 physical pixels. That is exactly the short edge of the iPhone 15 Pro, which Apple lists at 2556 by 1179 pixels. A guide that prints 393x852 in a table headed hardware resolution has mixed up the two units, and the gap between them is a factor of three.

Density Bug Classes

Density defects cluster into a small number of shapes. Knowing the shapes turns a vague report that something looks off into a specific check.

• Hairline borders vanish or double, because at a fractional ratio such as 1.5 a 1px rule maps to a non-integer number of physical pixels, and the renderer has to round somewhere.
• Canvas and chart output looks soft, because a canvas backing store sized in CSS pixels is stretched across three times as many physical pixels unless it is scaled by the device pixel ratio first.
• Logos and icons blur when a single 1x asset is served to a 3x screen, which is the failure Android's 3:4:6:8:12:16 scaling ratio exists to prevent.
• Screenshot comparisons fail on dimensions rather than content, because a capture at 3x returns an image three times wider than the stored 1x baseline.
• Tap targets that satisfy a pixel measurement in a mockup turn out undersized on hardware, since the physical size depends on density rather than on the CSS number.
• Media queries using min-resolution never fire in CI, which hides the entire high density branch of the stylesheet until a user reports it.

Every one of these passes a functional test suite. They are rendering defects, so they need a visual check that compares against a baseline captured at the same ratio, which is where per density baselines earn their cost.

Which Densities to Test

Testing every density is wasteful, and testing one is how the bugs above ship. Three integer ratios plus one fractional case cover the realistic range, and the decision is about which of them your traffic contains.

• Ratio 1 covers standard desktop monitors and is what a default cloud grid session already gives you, as the measurements above confirm.
• Ratio 2 covers Retina laptops and the large installed base of mid range phones, and it is the value MDN names as expected for HiDPI displays.
• Ratio 3 covers current flagship phones, and it is where asset selection and canvas scaling break first because the multiplier is largest.
• Fractional ratios appear wherever the operating system applies display scaling, which is why MDN types the value as a double rather than an integer. One targeted check is worth it, because rounding defects surface only when the ratio is not a whole number.

Emulation is the right tool for the first pass, since a deviceScaleFactor context is fast and runs on every commit. It has a real limit: it changes the numbers the page reports, not the font rasterization, the GPU, or the browser build underneath.

Confirming the result needs hardware. TestMu AI's real device cloud runs the page on physical handsets, each with its own screen resolution, chipset, and OS skin, and its Responsive Web Testing sessions validate breakpoint behavior, font scaling, and tap target sizing on those form factors. Font rasterization, GPU compositing, and OS-level display scaling behave there as they do for the user, which a scale factor override cannot reproduce.

For the browser side of the matrix, TestMu AI's test automation cloud runs 3,000+ browser and OS combinations in parallel. Pair that breadth with the checks in our responsive design testing checklist so the density cases sit alongside the layout cases instead of in a separate pass.

Conclusion

Open your test suite and search for deviceScaleFactor. If it does not appear, every test you own runs at ratio 1, and the measurements in this article show what that hides.

Add one context at ratio 2 and one at ratio 3 to the pages that carry logos, icons, or canvas output. Capture a visual baseline per ratio rather than a shared one, so a 3x capture is never compared against a 1x reference.

Then confirm on hardware, because emulation reports the numbers while a device renders the glyphs. You can check any page against a live grid with the screen resolution test tool, wire the same capabilities into your framework using the automation capabilities documentation, and run the whole matrix in parallel on TestMu AI's test automation cloud.