DeviceBenchFree screen resolution checker
Your screen resolution, and why it has two answers
This page reads your display twice and shows both readings next to each other: the device-pixel grid the monitor was sold with, and the smaller CSS-pixel grid every web page is handed once display scaling and browser zoom have taken their cut. Around them sit the browser window’s own size, the area left after the taskbar or Dock, color depth, orientation and the aspect ratio — eleven fields, re-read the moment you drag the window or change the zoom. All of it comes from the screen and window objects in this tab, and none of it includes a make, a model or a size in inches, because a browser is never told those.
- 100% free
- No signup
- Both pixel grids
- 11 browser fields
- Live on resize
Reading the screen. The figures appear one frame after this page finishes loading, because the HTML was built long before it met your display.
How to check your screen resolution
Three steps, and the middle one is the reason most people leave this page with a different number than they arrived expecting.
Read the two cards before anything else
The left card counts device pixels and is the figure a shop, a driver panel and a spec sheet all quote. The right card counts CSS pixels and is what every web page, every screenshot tool and every video-call layout works in. On a machine with no scaling the two agree; on a modern laptop the right one is commonly two thirds or half of the left one, and neither is wrong.
Press Ctrl+0 and see which figure moves
Resetting the browser zoom is a two-second experiment that settles the most common confusion on this page. If the CSS grid jumps and the pixel ratio changes with it, zoom was responsible for the number you were about to report. If both hold still, what remains is your operating system's display scale, and that lives in Settings rather than in the browser.
Copy the block when someone else has to read it
The copy button produces nine plain lines with both grids, the ratio, the window size and the orientation on them. Paste that into a support ticket instead of a screenshot: a helpdesk that asks for your resolution is usually trying to work out whether scaling is behind a blurry app, and the ratio is the line that answers it.
Technical specifications
| What a browser cannot report | The make, model, serial number or physical size of the display — nine of the eleven fields describe pixels and none describes hardware |
|---|---|
| Device-pixel grid | screen.width and screen.height multiplied by devicePixelRatio, which is the figure printed on the box |
| CSS-pixel grid | screen.width and screen.height as handed to layout, after the operating system scale and browser zoom have both applied |
| Pixel ratios in normal use | 1.00 unscaled, 1.25 and 1.50 on Windows laptops, 2.00 on Retina, 2.625 to 4.00 on Android handsets |
| Window figures | innerWidth includes the vertical scrollbar; innerHeight excludes the tab strip and address bar, worth 70 to 130 px |
| Resolutions named | 20 grids from 1280 × 720 up to 7680 × 4320, matched in either orientation |
| Re-read when | the window resizes, the device rotates, or a matchMedia watch on the current dppx value fires |
| Kept after the tab closes | Nothing — all eleven values are read again from scratch on the next visit |
Frequently asked questions
Why does my 4K laptop say 1920 × 1080 here?
Because the panel is 3840 × 2160 and your system is spending four device pixels on each CSS pixel, so layout is done on a 1920 × 1080 grid. That is a deliberate arrangement rather than a fault: text and icons drawn at 3840 pixels wide with no scaling would be roughly half the physical size they were designed at. The left card on this page shows the panel, the right card shows the grid, and the ratio between them is the scale factor at work.
The reading changed when I zoomed. Which figure does support want?
Give them the device-pixel figure and mention the ratio separately. Browser zoom multiplies into devicePixelRatio exactly the way the operating system's scale factor does, so at 150% zoom on an unscaled 1080p monitor the CSS grid drops to 1280 × 720 and looks like a completely different machine. The panel never changed, which is why the left card holds still while the right one moves.
What is the difference between the screen size and the browser window size?
The screen is the whole display and the window is the rectangle this page is being painted into, so the window figure is always smaller and it changes as you drag the edge of the browser. Two details catch people out: innerWidth counts the vertical scrollbar, which costs about 15 pixels in Chrome on Windows and nothing at all on a Mac with overlay scrollbars, and innerHeight excludes the tab strip and address bar, which together take between 70 and 130 pixels depending on your browser and toolbars.
Why is the usable height smaller than the screen height?
That gap is the space permanently reserved by the system chrome — the Windows taskbar, the macOS menu bar and Dock, a Linux panel. A 40-pixel taskbar on a 1080p display leaves availHeight at 1040, and a Mac with the menu bar showing and the Dock hidden reports 25 pixels less than the screen. It is the figure a maximized window can actually occupy, which is why full-screen apps use it rather than the raw screen height.
I have two monitors. Which one is this describing?
Whichever display this browser window is mostly sitting on, and it re-reads when you drag the window across. There is no web API that enumerates your displays without permission — the Window Management API exists in Chromium for that job and prompts before it will list anything — so a page like this one sees a single screen at a time. Dragging this tab to the other monitor and watching the numbers change is the fastest way to compare two panels.
Can this page change my resolution for me?
No, and nothing on the web can — the setting belongs to the operating system and a browser is never given a handle on it. On Windows it is Settings, System, Display, Display resolution; on macOS it is System Settings, Displays, where a Retina panel offers scaled modes rather than raw pixel counts; on GNOME it is Settings, Displays, Resolution. Only full-screen mode is under a page's control, and that changes what a page occupies rather than what the display is running at.
My monitor is HDR, so why does color depth say 24-bit?
Because colorDepth is a legacy field that nearly every browser hard-codes at 24, regardless of the panel or the pipeline behind it. Chromium reports 30 on a narrow set of high-bit-depth configurations and Firefox and Safari effectively never do, so a 24 here is not evidence about your monitor either way. Whether wide gamut is actually reaching the screen is a question for a CSS color-gamut media query, not for this field.
About CSS pixels, device pixels and the gap between them
For the first decade of the web a pixel was a pixel: the image was 400 units wide, the screen was 1024 units wide, and both units were the same physical dot. High-density panels ended that, and the CSS specification resolved it by redefining the pixel as a reference unit — an angular measure, anchored at 1/96 of an inch seen at arm’s length, rather than a hardware dot. Everything a browser lays out is expressed in that reference unit, and window.devicePixelRatio is the number of real dots the compositor spends on each one. So a 3840-pixel panel at a ratio of 2 behaves, for layout purposes, exactly like a 1920-pixel panel with sharper text, and screen.width honestly reports 1920 because that is the grid pages are being asked to work in.
The ratio is not one setting but the product of two, which is why the same monitor gives different answers on different days. The operating system contributes a scale factor — Windows offers 100%, 125%, 150% and 175%, macOS hides its equivalent behind named Scaled modes, GNOME has integer and fractional scaling — and the browser multiplies its own zoom level on top. A visitor who set the page to 110% two weeks ago and forgot has a ratio of 2.2 on a Retina display, and every figure derived from it moves with them. This page watches the ratio from the moment it loads for exactly that reason: if it changes while you are here, the change came from your side of the glass, not from the panel. The same arithmetic underlies why an on-screen ruler has to be calibrated before it can claim a centimeter, and why a pixel-density calculator has to ask you for the diagonal instead of reading it.
What is genuinely absent from the browser is worth knowing before you go looking for it. There is no field for the panel’s make or model, none for its physical dimensions, and none that enumerates a second monitor without an explicit permission prompt — the Window Management API was added to Chromium precisely because the older screen object describes one display at a time. Refresh rate is missing too, which is why it has to be measured from the frame schedule rather than read. If you want the rest of what this machine will admit to — cores, memory, platform, touch support — the device info page collects it and marks the values browsers deliberately round off.
What is done with the eleven values
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
Screen dimensions are a well-known ingredient of browser fingerprinting, so it is worth being precise about this page: the eleven values are read, rendered, and read again on the next resize, and at no point are they hashed, combined with anything else or sent to a server. The copy button is the only route off the page, and you have to press it.