A display size test is a browser-side check that reports the CSS screen width and height, available screen area, viewport, outer window, and the browser's device pixel ratio in a single labeled report, and it never measures physical inches. The report is built from standard values the browser already exposes: screen.width and screen.height describe the coordinate space given to web content, while screen.availWidth and screen.availHeight may exclude operating-system regions such as a taskbar or menu bar. window.innerWidth and window.innerHeight give the layout viewport, and window.outerWidth and window.outerHeight report the outer browser window whenever the browser provides them. devicePixelRatio is the multiplier the browser uses between CSS coordinates and the backing store. Together these fields let you compare the coordinate environment a web page sees right now against the one it saw a moment ago, after a resize, a zoom change, or a move to another display. The test is local: no values are uploaded, no history is kept, and a Copy report button places the visible fields on your clipboard as plain text.
What a Display Size Test Actually Measures
Most searchers looking for a display size test want to know two related but distinct things: how big the panel is in inches, and how big the coordinate space is for web pages. A browser page cannot answer the first question because ordinary JavaScript does not have access to a calibrated ruler, EDID data, or trustworthy hardware DPI. What it can do is report the second question accurately, with explicit labels, every time the browser reads its window or screen objects. The Screen Resolution Checker sits in that second category. It reads positive finite values from the screen, window, and devicePixelRatio objects, labels them clearly, and lets you copy them as a plain-text record. Anything that goes beyond those values — physical diagonal, dot pitch, brightness, panel type, refresh rate, HDR, color gamut, cable capability — is outside what a normal web page can deliver and would require operating-system display settings, manufacturer specifications, or dedicated hardware tools.
The Fields Compared in a Display Size Test
A single report typically puts four width-by-height measurements side by side, plus two derived values and one orientation label. Each field comes from a different browser object, so it changes for a different reason. The table below names every field the widget exposes, the source it comes from, and what it really represents.
| Field | Source | What it represents |
|---|---|---|
| CSS screen (W × H) | screen.width, screen.height | The coordinate space exposed to web content; not necessarily the panel's marketed resolution. |
| Available screen | screen.availWidth, screen.availHeight | CSS screen minus any area taken by OS interface elements such as a taskbar. |
| Viewport | window.innerWidth, window.innerHeight | The layout viewport available to the page right now; changes when the user resizes. |
| Outer window | window.outerWidth, window.outerHeight | The full browser window including chrome; falls back to the viewport when unavailable. |
| devicePixelRatio | window.devicePixelRatio | The browser's multiplier between CSS coordinates and the backing store. |
| Estimated device pixels | round(CSS screen × ratio) per axis | A clearly labeled estimate; not a guarantee of native panel resolution. |
| Orientation | Comparison of CSS width and height | Landscape, Portrait, or Square; a label, not an accelerometer reading. |
When the CSS screen field is wider than the available screen field, the difference is the area the operating system is reserving at the edges. When the outer window field is larger than the viewport field, the difference is roughly the browser chrome — title bar, tabs, side panels, developer tools, and any platform-specific decorations. When the viewport is smaller than the CSS screen, the browser window is simply not maximized, or the page is being shown at a non-default zoom.
How to Run a Display Size Test
Open the Screen Resolution Checker page in the browser and tab you want to inspect. The page populates the report immediately from the current browser state, so the first thing you should do is read all four dimension rows plus the ratio row and write down the conditions you observed: which monitor the window is on, whether the window is maximized, what zoom level is set, and whether developer tools are docked. Those conditions are part of the test, not metadata about it.
- Open the page and compare the CSS screen, available screen, viewport, and outer-window rows. Note any field that is zero, missing, or negative; the widget rejects those inputs.
- Review devicePixelRatio and the labeled estimated device-pixel multiplication. Treat the multiplication as an estimate, never as the panel's native resolution.
- Resize or move the browser window when comparing conditions. The viewport and outer-window rows update on resize; the CSS screen rows only change when the browser window crosses into a different coordinate space.
- Change one condition at a time — zoom level, fullscreen, monitor, OS scaling — and select Copy report between changes so you can diff the visible fields.
- Compare the two reports field by field. A change in the viewport row but not the CSS screen row indicates a window resize; a change in the CSS screen row indicates the window moved to a different display or the browser re-reported its coordinate space.
Reading devicePixelRatio and the Estimated Pixels
The widget multiplies the CSS screen width by devicePixelRatio and rounds to a whole number for each axis, then displays the result as estimated device pixels. The arithmetic is straightforward; the interpretation is where readers go wrong. If the CSS screen is 1440 × 900 CSS pixels and the browser reports a devicePixelRatio of 2, the estimate is round(1440 × 2) × round(900 × 2), or 2880 × 1800 estimated device pixels. That multiplication is one of the labeled steps the widget performs; the orientation classification, which compares the reported CSS width and height, is the other. The 2880 × 1800 figure is what the browser's coordinate system would suggest for a backing store of the same physical extent, but display scaling, browser zoom, operating-system scaling, compositor behavior, screenshots, remote desktops, multi-panel setups, and privacy reduction can all push the real native panel away from that number. Treat the estimate as a sanity check on the ratio, not as a measurement of pixels per inch.
Conditions That Change the Reported Numbers
Most of the troubleshooting value of a display size test comes from changing one thing and watching which row moves. The table below pairs common changes with the row that responds and the most likely cause when the response looks wrong.
| Condition change | Row that typically changes | Why it can confuse a reader |
|---|---|---|
| Drag the window edge to resize | Viewport, outer window | CSS screen fields stay the same; only the viewport and outer window respond to the resize, since available screen is reported by the operating system and is independent of the browser window. |
| Browser zoom in or out | Viewport, CSS screen can stay | Zoom changes the layout viewport without changing the underlying CSS coordinate space in every browser. |
| Enter fullscreen | Outer window approaches viewport | Chrome disappears so the outer window becomes close to the viewport. |
| Move window to another display | CSS screen, available screen | Different displays expose different coordinate spaces, sometimes even when their pixel counts match. |
| Change OS scaling (Windows display settings, macOS Resolution) | CSS screen, devicePixelRatio | OS scaling can reduce the reported CSS coordinate space and lower the ratio at the same time. |
| Open or close the developer tools dock | Viewport | The dock steals layout viewport space; the outer window can grow or stay flat. |
| Remote desktop or virtualized session | CSS screen, devicePixelRatio | The reported values belong to the virtual display, not the host panel. |
| Browser privacy reduction mode | CSS screen | Some browsers lower precision or report rounded values to limit fingerprinting. |
The conditions list is the reason the widget keeps no history. Two consecutive reports copied before and after a single change are the entire debugging artifact; the conditions that produced them belong in your notes, not in the page. For a guide that works across browsers rather than one specific tab, see how to check screen resolution in any browser, which walks through the same field-by-field comparison in a wider context.
What This Test Cannot Tell You About Your Display
Even when every row is filled in and the multiplication lines up nicely, the widget still cannot answer a long list of questions that readers often expect it to. It cannot measure inches or centimeters, dots per inch, pixel pitch, color depth, refresh rate, HDR capability, color gamut, brightness, panel type, physical diagonal, cable bandwidth, GPU output mode, or EDID data. None of those numbers travel through the screen, window, or devicePixelRatio objects, and a normal web page does not have permission to read them. If you need any of those values for purchasing, diagnosing, or calibrating a display, use the operating-system display settings, the manufacturer's specification sheet, or a dedicated hardware tool. The display size test is a description of what this browser is currently telling your code, not a description of the hardware behind the panel.
Run the test on the machine and tab you care about, copy the report before and after each condition change, and keep your notes about zoom, monitor placement, and fullscreen state outside the widget — the page intentionally saves no history and uploads nothing. When the report changes unexpectedly, the diff between two copies tells you which row the browser moved and which row stayed put, which is usually enough to identify the layer that changed.
If you're weighing options, Drawing Board Online vs Amazon: Which One Actually Works? covers this in detail.