Screen Resolution Checker

See your screen, available desktop, live viewport and device pixel ratio, plus an estimated refresh rate and pointer and color capabilities.

This report is computed locally from standard browser APIs. Nothing is uploaded, stored or shared.

This is a CSS-pixel report, not hardware truth: browsers and OS scaling can change these numbers, so they may differ from the panel's native resolution.

Screen

—

Full display size as the browser reports it, in CSS pixels.

Available desktop

—

Screen minus taskbars and docks — this is the space a maximized window can take.

Browser viewport

—

The page area right now; resize the window and it updates live.

Device pixel ratio

—

Real panel pixels behind the CSS pixels above — multiply to get physical size.

Orientation: —
Color depth: —
Pointer type: —
Color gamut: —

Refresh-rate estimate

—

Frames are counted for 2 seconds. Results are vsync-capped and browsers throttle background tabs, so treat this as a lower-bound estimate, not a spec sheet number.

How It Works

The four main cards read four nested rectangles. window.screen.width/height report the full display as the browser sees it; availWidth/availHeight subtract the OS chrome (taskbar, dock) that a maximized window cannot cover; innerWidth/innerHeight measure the actual rendered page area and re-measure on every resize; and devicePixelRatio scales each of those CSS pixels to the physical panel pixels behind them.

CSS pixels vs device pixels
A CSS pixel is the unit web layout uses, and on a HiDPI ("retina") display one CSS pixel is drawn with 2×2 or 3×3 real screen pixels — that multiplier is the device pixel ratio. So a 1280 CSS-wide viewport on a DPR-2 phone is actually 2560 panel pixels wide. The DPR card multiplies screen width and height by the ratio to show the physical figures, and browser zoom or OS display scaling changes the CSS numbers, never the panel itself.
Why availWidth is smaller than width
The operating system reserves strips of the desktop for the taskbar, dock or menu bar, and availWidth/availHeight report the rectangle that is left over. A 1920 × 1080 display with a Windows taskbar typically reports about 1920 × 1040; on a second monitor without chrome the two figures can match, and on phones they both report the browser's notion of the screen, which is itself approximate.
Media queries for pointers and gamut
The capability chips come from matchMedia tests: (pointer:fine) means a precise device like a mouse or trackpad, (pointer:coarse) means touch, and (hover:hover) means the device can rest a cursor on elements — phones report coarse and no-hover. (color-gamut: p3) answers whether the display can show wider-than-sRGB colors, and the refresh estimator simply counts requestAnimationFrame callbacks for two seconds, which is why it reports what the browser achieves rather than what the panel can do.

Frequently Asked Questions

Can I see my monitor's true native resolution?

Not reliably from a web page. Browsers deliberately expose scaled, CSS-level numbers, not the panel's hardware mode, and the OS display scale, browser zoom and fullscreen all rewrite them. For the native figure, check your OS display settings (Windows: Settings > System > Display; macOS: About This Mac) or the monitor's own on-screen menu — those read the hardware directly.

Why do the numbers change when I zoom or use HiDPI?

Because every value here is in CSS pixels. A 200% browser zoom halves the reported viewport and screen sizes; a HiDPI display keeps the CSS numbers but raises devicePixelRatio, so more real pixels render each CSS pixel. The DPR card shows the physical-pixel equivalent so you can see both layers at once.

My phone shows different numbers sideways — is that wrong?

No: rotating swaps width and height in every readout, and the viewport card re-measures on the orientation change. Notches and system bars shift the available-desktop figures too, which is normal behavior of the underlying APIs.

The refresh estimate said 60 but my screen is 120 Hz — why?

Browsers sync animation frames to vsync and typically cap at 60 Hz unless the page is marked as animation-critical; power-saving modes and battery saver also clamp it. A reading of about 60 on a 120 Hz panel is a browser limit, not a screen fault, and this page cannot prove the higher rate — it can only show what it actually achieves.

Is anything uploaded to a server?

No. The report is assembled from local browser APIs (window.screen, matchMedia, requestAnimationFrame) inside this page and never sent anywhere. The copy button only puts text on your own clipboard.