How to Check Your Screen Resolution and Viewport Size

Screen resolution is the full pixel grid of the monitor (or the OS-reported screen), such as 1920×1080 or 2560×1440. Viewport size is the visible area inside the browser window for your page — usually smaller once you subtract toolbars, sidebars, window chrome, and any OS taskbar if the window is not fully maximized.

• Screen — hardware / OS display metrics (often screen.width × screen.height in browsers)
• Viewport — layout viewport for CSS and media queries (often close to window.innerWidth × window.innerHeight)
• Why both matter — shopping for a monitor needs screen numbers; debugging a layout needs viewport numbers

Open the free screen resolution checker and compare the two readouts. Maximize the window and watch the viewport grow; the screen figures should stay put unless you change display mode or move to another monitor.

Mobile browsers add another twist: dynamic toolbars can shrink or grow the visual viewport as you scroll. Always recheck on the real device when a “mobile bug” only appears with the URL bar expanded or collapsed.

On HiDPI and Retina displays, one CSS pixel is often backed by multiple physical hardware pixels. Device pixel ratio (DPR) is roughly physical pixels per CSS pixel along one axis.

• DPR 1 — classic 1:1 mapping; common on many older or lower-density office monitors
• DPR 2 — typical “Retina” style scaling; 2×2 physical pixels per CSS pixel
• Fractional DPR — 1.25, 1.5, 1.75 appear when OS display scaling is set to 125%, 150%, and similar values

If the OS scales the UI to 150%, browsers report CSS dimensions that already reflect that scaling. A “1920×1080” panel at 150% scaling does not give you a 1920-CSS-pixel-wide layout viewport when maximized — the usable CSS width is smaller. That is expected, not a bug in the checker.

Designers export 2× image assets so photos stay sharp on DPR 2 screens. Developers use srcset, image-set, or density descriptors so the browser can pick a sharp file without shipping huge images to every phone.

When you need aspect ratios for frames, videos, or responsive media boxes, pair this with the aspect ratio calculator and the aspect ratio guide.

You do not need a downloadable utility for most day-to-day checks. A browser page that reads standard display APIs is enough for:

• Remote support — “What resolution is that laptop?” without walking someone through OS menus
• QA and bug reports — attach viewport and DPR next to a screenshot of a broken layout
• Buying decisions — confirm the active mode matches the panel’s advertised resolution
• Presentation setup — dual monitors and projectors often switch modes silently
• Accessibility — large OS scaling changes effective CSS space; measure before blaming the stylesheet

The free screen resolution checker updates as you resize, so you can drag the window to a common breakpoint width and read the live viewport. That is faster than guessing whether a layout broke at 768, 900, or 1024 CSS pixels.

For physical units (inches, centimeters) when a spec sheet mixes measurement systems, use the unit converter and the unit conversion guide alongside diagonal size math from the manufacturer.

CSS media queries key off the viewport, not the marketing resolution on the monitor box. A full HD panel with a half-width browser window behaves like a narrow layout for your page.

• Breakpoints — test at the widths your CSS actually uses (for example 640, 768, 1024, 1280)
• DevTools device mode — useful, but always spot-check real phones; browser chrome differs
• Landscape vs portrait — rotate and re-read viewport; height constraints break sticky footers and 100vh patterns
• Zoom — browser zoom changes CSS pixels available; users who zoom to 125% are a real audience

When a component “only fails on my machine,” compare viewport and DPR from the checker with a teammate’s report. Matching screenshots at different DPRs can hide 1-pixel rounding issues and hairline borders that thicken on fractional scales.

Color and contrast requirements still apply at every size. After layout checks, validate text and UI contrast with the color contrast checker and the contrast guide so responsive type remains readable.

People mix labels constantly. Clearing the vocabulary prevents bad tickets and bad purchases.

• Resolution vs refresh rate — 144 Hz is about motion smoothness, not 1440p sharpness
• Resolution vs diagonal inches — 27″ and 24″ panels can share 1440p with different pixel density
• Native vs scaled resolution — running a 4K panel at 1080p “for performance” blurs UI text
• TV “4K” vs browser CSS width — living-room browsers still report a scaled viewport, not raw 3840 CSS pixels in many setups
• Multiple monitors — APIs often describe the current screen; move the window and recheck

If the checker shows unexpected values, move the browser fully onto one display, set scaling to 100% temporarily, and remeasure. Then restore the scaling you actually use daily — that is the environment real users have.

Video call quality is a separate pipeline (camera sensor, encode, network). When the face is soft but the UI is sharp, test the camera with the webcam tester and the webcam testing guide instead of chasing monitor resolution.

A complete pass takes under a minute and gives you numbers you can paste into a bug report.

1. Open the free screen resolution checker in the browser you care about.
2. Read screen width and height as the display-level metrics.
3. Read viewport width and height as the layout area available to the page.
4. Note device pixel ratio for HiDPI / Retina / OS scaling context.
5. Resize the window and confirm the viewport updates in real time.
6. Maximize, then restore, to see the range you actually use while browsing.
7. If you use multiple monitors, drag the window to each display and record both setups.

Include browser name and OS scaling percentage in any QA note. Two people on “1080p laptops” can still disagree on layout if one runs 125% scaling and the other runs 100%.

Generatr’s checker runs client-side with live updates — no install, no account. Use it whenever you onboard a new monitor, debug a breakpoint, or document a display-related bug.

Small habits make resolution data more useful over time.

• Write both pairs — always log screen and viewport together so readers know which number is which
• Capture DPR — fractional scales explain many “fuzzy border” tickets
• Test zoom 90–125% — accessibility users change zoom without changing hardware
• Prefer native mode — non-native monitor resolutions often blur text
• Match design tokens to CSS pixels — Figma frames at 1440 width map to viewport width, not panel marketing labels

When you convert spacing systems or document physical sizes for print-adjacent work, keep the unit converter guide nearby. For media framing, keep the aspect ratio guide open so width/height pairs stay consistent across breakpoints.

Display metrics will not fix a bad color palette. After sizes look right, re-check contrast and hierarchy so the UI remains usable on both bright offices and dim rooms.