Your screen resolution in device and CSS pixels, viewport size, pixel ratio, refresh rate and colour depth — read live in your browser.

Three numbers, all called “resolution”

The reason this question has confusing answers is that a modern screen has several resolutions at once, and different tools report different ones:

	What it is	Example on a 2× laptop
Device pixels	what the panel draws	2880 × 1800
CSS pixels	what a web page measures in	1440 × 900
Viewport	the CSS pixels this window has	1440 × 780

A web page cannot read the panel directly. It gets CSS pixels and a device pixel ratio, and the device figure above is the two multiplied. That is why a site can tell you your “resolution” is 1440×900 when you bought a 2880×1800 machine, and neither is wrong.

Device pixel ratio

The ratio is how many device pixels make up one CSS pixel along each axis:

DPR	Means
1	one device pixel per CSS pixel — an ordinary desktop monitor
2	Retina and most modern laptops and phones
3	high-end phones
Fractional, e.g. 1.5, 2.625	Windows display scaling, Android, or browser zoom

Browser zoom changes it. Zooming to 150% on a 2× display gives a DPR of 3, and the CSS resolution shrinks to match. If the numbers on this page look wrong, check the zoom level first — that is the usual explanation.

Because of scaled display modes, “device pixels” here is what the browser renders to, which on a scaled macOS or Windows setting is not always the panel’s own pixel count. It is the resolution that matters for choosing an image; it is not a specification lookup.

Which one to design for

CSS pixels, always. A layout written in CSS pixels is the same physical size on a 1× and a 2× screen, which is the entire point of the abstraction — a 16px font is legible on both, and would be microscopic on one of them if CSS measured device pixels.

The ratio matters for one thing: raster images. A 400 CSS-pixel-wide image needs 800 device pixels of data to look sharp at DPR 2, which is what srcset and 2x are for. Vector formats and text need nothing; they are rendered at whatever the device asks for.

Screen, window, viewport

Reading	Excludes
Screen	nothing — the whole display
Available screen	the taskbar or dock
Window	nothing — including the browser’s own chrome
Viewport	chrome, toolbars, scrollbars

The viewport is the only one a page can actually lay out inside, and the only one that responds to media queries. On a phone it also changes as the address bar hides and reappears during scrolling, which is why fixed-height layouts using 100vh behave oddly there.

Refresh rate is measured, not reported

There is no API that tells a page the refresh rate. The figure here is measured: count animation frames over a second and divide, then round to the nearest rate displays are actually built at.

That makes it a floor rather than a fact:

A busy page or a slow machine drops frames, and the measurement reads low.
A background tab is throttled to roughly 1 Hz.
Some browsers cap animation frames at 60 regardless of the panel.
A variable-refresh display genuinely has no single rate.

If the answer looks low, run it again with nothing else happening. If it reads 60 on a 120 Hz display, that is more likely to be the browser than the screen.

Colour depth

Almost every browser reports 24-bit — eight bits each for red, green and blue, which is 16.7 million colours. This is one of the values browsers deliberately freeze to reduce fingerprinting, so a 10-bit HDR panel usually still reports 24. A page cannot see the difference; a colour-managed application can.

Everything here is read locally

Every figure comes from your own browser’s view of itself. Nothing is sent anywhere. The one thing about your machine that genuinely cannot be answered locally is its public address — see what is my IP.

What is my screen resolution