Utilities / UTL-02 Runs in your browser
What Is My Screen Resolution: Display, Viewport and Pixel Ratio
Your screen size, the browser viewport, the device pixel ratio and the breakpoint band your viewport falls in right now — all read from your own browser, and all updating as you resize the window.
Utility UTL-02 Live — resize and watch
- Screen, CSS pixels
- —
- Browser viewport
- —
- Device pixel ratio
- —
- Screen, hardware pixels
- —
- Available screen area
- —
- Orientation
- —
| Property | Value | What it measures |
|---|
Three numbers that all get called resolution
Ask what resolution a display is and you can get three different correct answers. The panel above reports all three rather than picking one.
The hardware figure is how many physical pixels the panel has. It is the number on the box, and the browser will not tell you it directly; it has to be reconstructed by multiplying.
The CSS figure is what the browser reports as the screen. On a display with any scaling applied it is smaller than the hardware figure, by exactly the device pixel ratio. A ratio of 2 means every CSS pixel is drawn with four hardware ones, which is why text on such a display looks sharper without looking smaller.
The viewport is the area your page actually occupies. It is the smallest of the three and the only one that affects layout.
Why the viewport is the number that matters
CSS media queries are evaluated against the viewport. A visitor on a large monitor with a half-width window gets your narrow layout, and that is correct behaviour rather than a bug.
This has a practical consequence for anyone reading analytics. Screen-resolution reports in analytics tools usually record the screen, not the viewport, so a report full of 1920-wide visitors does not mean your 1920-wide layout is what most of them see. If your tool can record viewport width, that column is the one worth looking at.
It also means testing by resizing a desktop window is a legitimate check. Drag the edge, watch the breakpoint line above change, and you are exercising the same code path a smaller device would.
Device pixel ratio, and where it bites
The ratio is why a logo can look crisp on one machine and soft on another. An image displayed 200 CSS pixels wide needs 400 real pixels on a ratio-2 display to look sharp, and supplying only 200 makes it visibly blurry to anyone on a modern laptop or phone.
The other direction costs money rather than quality. Serving a 1600-pixel image into a 400-pixel slot wastes most of the bytes and slows the page for everyone. Both problems are solved by the same mechanism: a set of widths in a srcset attribute, with the browser choosing based on the ratio it knows about and you do not.
Ratios above 2 are common on phones, and 3 is normal on flagship devices. That is the practical ceiling worth serving; a fourth size rarely earns its bytes.
The viewport that will not hold still on a phone
On a mobile browser the viewport height changes while you scroll. The address bar retracts, the visible area grows by fifty or sixty pixels, and anything sized to the full height jumps at exactly the moment the reader is trying to read it.
This is why a section set to a hundred per cent of viewport height looks correct in a desktop window and wrong on a phone: the value it was measured against changes underneath it. The dynamic viewport units solve it directly. One of them tracks the largest possible height, one the smallest, and one the current value, so a layout can be pinned to whichever of the three actually suits it.
The number reported above is the current one, measured at this instant. Scroll this page on a phone and watch the height figure move while the width stays put. That is the whole problem, visible in one reading, and it is the reason full-height sections are worth avoiding unless you have a specific reason to want one.
Reading the breakpoint line
Underneath the table is the band your viewport currently falls in, named against 640, 768, 1024, 1280 and 1536 pixels, the widths the mainstream CSS frameworks have converged on, so the reading means something whichever one you use. They are a common vocabulary, not a rule: a layout is free to break wherever its own columns get too narrow.
It is there so the abstraction becomes concrete. Drag the window edge and the label changes the moment the viewport crosses one of those widths, which is the same crossing your own media queries are watching for.
The values are read fresh on every resize and orientation change, with the handler throttled to animation frames so dragging a window edge stays smooth. Everything comes from your own browser and none of it leaves the page.
Questions people ask
Why is my screen reported as 1920 by 1080 when the specification says 3840 by 2160?
Because the browser reports CSS pixels, not hardware pixels. A display running at 200 per cent scaling shows 1920 CSS pixels across 3840 hardware ones, and the device pixel ratio of 2 is what reconciles the two.
Multiply the reported width by the pixel ratio and you get the physical figure back. Both numbers are shown above so the arithmetic is visible rather than implied.
What is the difference between screen size and viewport?
Screen size is the whole display. Viewport is the area inside the browser where your page is drawn, so it excludes the window chrome, the tabs, the bookmarks bar, any open developer tools and the scrollbar.
The viewport is the figure that matters for layout, because that is what CSS media queries are measured against. A visitor on a 1920-wide screen with a half-width window is a 960-wide visitor as far as your stylesheet is concerned.
Which number should I use when designing breakpoints?
Neither, on its own. Set breakpoints where your own layout starts to look wrong, then check the result against real viewport widths in your analytics.
Designing to device specifications is how sites end up with a gap between two popular sizes. Designing to the point where a column gets too narrow to read produces breakpoints that hold for devices nobody has shipped yet.
Why does the available screen area differ from the screen size?
The operating system reserves space: a taskbar, a dock, a menu bar. The available figure subtracts those, so it is the largest a browser window could actually be.
The gap is usually a few dozen pixels vertically and nothing horizontally, but on a system with a side-docked taskbar it shows up on the width instead.
The viewport number does not change when I zoom.
It should, and it does. Zooming changes how many CSS pixels fit, so the reported viewport width goes down as you zoom in. If it looks static, the reading may not have refreshed; resize the window slightly to force an update.
Browser zoom and device pixel ratio interact here: on many browsers zooming also changes the reported ratio, which is why both figures are listed side by side.
Is anything I type sent anywhere?
No. The tool runs in this page and there is no server behind it, so nothing you type is transmitted, logged or stored. Disconnect from the network, reload from cache, and it still works.