Chrome reports screen resolution as a set of CSS pixel values pulled from the browser's screen and window objects — specifically screen.width, screen.height, screen.availWidth, screen.availHeight, window.innerWidth, window.innerHeight, window.outerWidth, window.outerHeight, and window.devicePixelRatio. These numbers describe the coordinate space the browser exposes to web content rather than the panel's marketed or native pixel count, so a normal page never directly reads the physical diagonal, the EDID, or a calibrated DPI from this API surface. Because Chrome may sit in a window of any size, snap to part of a desktop, share the screen with another monitor, or run inside a remote session, the figures are simply the snapshot the current tab actually sees. The Screen Resolution Checker opens as a focused page, reads each value locally, labels every field in plain language, multiplies the CSS screen dimensions by devicePixelRatio to estimate the backing-store pixels, and lets you copy a plain-text report. No display identifier, clipboard content, or dimension is uploaded, and the widget intentionally saves no history between visits.
What Chrome Calls a Screen Resolution
When a Chrome tab asks for "screen resolution," the answer it gets back is a bundle of separate numbers rather than one figure. Each one answers a slightly different question, and the tab only ever sees what its current browser window and operating-system session are willing to expose. Mixing these values up is the most common reason a Chrome reading looks "wrong" compared to the spec sheet on the monitor box.
The first pair, screen.width and screen.height, reports the full CSS pixel coordinate space of the display or virtual display Chrome currently considers its home screen. The second pair, screen.availWidth and screen.availHeight, is the same coordinate space minus any region the operating system has reserved — a Windows taskbar, a macOS menu bar, a docked panel, or a Chrome OS shelf can each shrink the available area. The third pair, window.innerWidth and window.innerHeight, is the viewport — the rectangle inside the browser chrome where layout actually paints. The fourth pair, window.outerWidth and window.outerHeight, is the entire browser window including its title bar, tabs, side panels, developer tools, and platform decorations. Finally, window.devicePixelRatio is the multiplier Chrome uses when it wants to address the higher-resolution backing store behind a CSS pixel.
None of these nine values is the panel's native addressable pixel count by itself. The panel's marketed resolution is a hardware property that lives behind EDID, EDID-like extensions, and GPU output modes — surfaces a normal web page cannot read. The Chrome numbers are what Chrome is willing to tell a page about its coordinate environment right now.
How to Check Screen Resolution in Chrome
- Open Screen Resolution Checker in a Chrome tab so the page can read its own window and screen values without competing layout shifts from other content.
- Read the labeled fields on the page: full CSS screen, available screen area, current viewport, outer browser window, device pixel ratio, and the estimated device-pixel multiplication. Treat every value as a local snapshot from this browser, this window, this display, this moment.
- Resize or drag the Chrome window to a different size or to a different monitor when you want to compare conditions. The viewport and outer-window numbers refresh on the resize event; CSS screen and available screen numbers only change when Chrome itself reports a new environment.
- Move the browser between displays, enter fullscreen with F11, change Chrome's zoom with Ctrl and + or Ctrl and −, or change the operating-system scaling, then look at the screen and viewport fields again to see what actually shifted.
- Select Copy report on the widget to place the currently visible fields as plain text on the clipboard. Paste the text into a note, ticket, or chat so you have a record of the conditions, since the page intentionally saves no history between visits.
Reading Each Field in the Report
The widget labels every field separately on purpose, because Chrome returns these values as raw numbers with no built-in context. The table below pairs each field with the browser source and the question it actually answers.
| Field in the report | Browser source | What it answers |
|---|---|---|
| Screen (CSS) | screen.width, screen.height | Full CSS pixel coordinate space of the current display |
| Available screen | screen.availWidth, screen.availHeight | Screen space minus taskbar, menu bar, dock, or shelf reservations |
| Viewport | window.innerWidth, window.innerHeight | Layout area inside the browser chrome available to the page |
| Outer window | window.outerWidth, window.outerHeight | Full browser window including title bar, tabs, panels, decorations |
| Device pixel ratio | window.devicePixelRatio | Multiplier Chrome uses for the backing-store pixels |
| Estimated device pixels | round(CSS screen × devicePixelRatio) | Backing-store size estimate, clearly labeled as an estimate |
| Orientation | Compared CSS width and height | Landscape, Portrait, or Square label only |
For a concrete Chrome example, a tab reporting a CSS screen of 1440 × 900 with devicePixelRatio 2 yields estimated device pixels of round(1440 × 2) × round(900 × 2) = 2880 × 1800. The widget labels that result as an estimate rather than the panel's native count.
Two Chrome fields are easy to confuse: available screen and viewport. Available screen is set by the operating system and does not include taskbars or docks; viewport is set by the browser chrome and does not include tabs, address bar, bookmarks bar, side panel, or developer tools. Both can shrink the layout area, and both can be smaller than the full CSS screen at the same time.
When the Chrome Values Change
Because each field has its own source, each one reacts to a different kind of change. Knowing the trigger makes a Chrome reading far easier to interpret, especially when something looks wrong after a settings tweak.
- Resizing or dragging the Chrome window updates viewport and outer window immediately. Full CSS screen and available screen do not change unless the move also crosses into a different monitor with a different reported size.
- Chrome's zoom command (Ctrl and +, Ctrl and −, Ctrl and 0) changes the layout viewport but usually leaves the outer window and CSS screen values alone. The page effectively sees a larger or smaller drawing area.
- Browser side panels, vertical tabs, the bookmarks bar, and Chrome's developer tools each take space from the viewport and grow the outer window. Toggling them is a quick way to confirm which field is sensitive to chrome changes.
- Chrome OS shelf, Windows taskbar, macOS menu bar, or a docked panel can shrink available screen while leaving the CSS screen and viewport alone.
- Fullscreen (F11 on desktop, the fullscreen button in the tab UI) usually pushes the outer window up and gives the viewport almost the entire screen.
- Moving the window between two monitors with different scaling or sizes can change every field at once, which is the fastest way to verify a multi-display setup.
- Remote desktop, casting, virtual displays, and privacy-reduced browsers may report a fixed or rounded coordinate space that does not match the actual panel's native pixels.
A useful Chrome troubleshooting habit is to copy the report before a change and again after, then read the diff. The widget intentionally saves nothing between visits, so the only record is the clipboard snapshot you keep. Recording the conditions outside the page — zoom level, fullscreen state, which monitor, which scaling factor — turns that diff into a useful diagnosis instead of a mystery.
What This Tool Does Not Measure
The numbers Chrome exposes through screen and window are coordinate-space values, not hardware measurements. The widget explicitly avoids pretending otherwise, and it is worth listing the gaps so the report is not over-read by a Chrome user who is trying to compare it to a panel's spec sheet.
- Physical size: no inches, centimeters, diagonal, or pixel pitch. The browser has no calibrated ruler.
- DPI or pixel density: devicePixelRatio is a CSS-to-backing-store multiplier, not a trustworthy hardware DPI.
- Panel identity: no monitor brand, model, serial number, EDID block, or GPU output mode.
- Color and brightness: no color depth, gamut, refresh rate, HDR capability, nits, or panel type.
- Physical arrangement: the orientation label compares two numbers and does not read an accelerometer, a hinge, a folding state, or a multi-monitor geometry.
- Native addressable pixels: the estimated device-pixel multiplication can disagree with the panel's native count because of scaling, zoom, compositing, remote display, or privacy reduction.
For any of those questions, the right move is to open the operating-system display settings, consult the manufacturer's spec sheet, or use a dedicated hardware tool. The Chrome widget's job is narrower: read the browser's coordinate environment, label it honestly, and let the user decide whether the rest of the layout story is reasonable.