Screen Resolution Checker
Every measurement the browser reports, each next to what it actually measures, since screen, window, viewport and pixel ratio are four different numbers.
Viewport the area a page can draw in, in CSS pixels. This is what your media queries match against.
—Breakpoint band which of the common framework breakpoints this viewport width falls into.
—Window innerWidth and innerHeight, which include the scrollbar the viewport excludes.
—Taken by the scrollbar the difference between the two above, which is why a 100vw element can overflow.
—Screen the display in CSS pixels, not hardware pixels, and not the size of this window.
—Screen, minus system UI what is left after a taskbar or dock, which is what a maximised window gets.
—Device pixel ratio hardware pixels per CSS pixel. It changes with browser zoom, so it is a measurement rather than a property of the device.
—Screen in hardware pixels the CSS size multiplied by the ratio, which is the number a spec sheet quotes.
—Aspect ratio of the screen, named where it matches a common one.
—Orientation of the viewport rather than of the device, which is the one CSS cares about.
—Colour depth bits per pixel as reported by the browser, which is almost always 24.
—Touch available whether touch points exist, which is not the same as the device being a phone.
—Colour scheme preference what prefers-color-scheme reports right now.
—Reduced motion whether prefers-reduced-motion is set, which decides whether your animations should run.
—Resize the window and the numbers follow. Nothing here is sent anywhere: the page reads your browser and prints what it says.
Four numbers get used as if they were one, and this tool separates them.
The screen is the display, measured in CSS pixels, which is not its size in hardware pixels. The
window is innerWidth and innerHeight, which include the scrollbar. The viewport is the part a
page can actually draw in, which is what your media queries match against. And the device pixel ratio
says how many hardware pixels one CSS pixel covers, which is not a property of the device: it changes with
browser zoom.
So “my screen is 1920 by 1080” and “my viewport is 1920 by 1080” are almost never both true, and a bug report that gives one while meaning the other is why every row here says what it measures.
How to use
- Read the viewport row first. That is the number your CSS is responding to.
- Resize the window. Everything follows, which is the point: a viewport is a measurement, not a fact about the machine.
- Check the device pixel ratio if an image looks soft. A ratio of 2 or 3 means a 1x asset is being stretched.
Example
On a 14-inch laptop at default zoom:
Viewport 1425 × 812
Breakpoint band desktop, xl
Window 1440 × 812
Taken by the scrollbar 15px
Screen 1440 × 900
Screen, minus system UI 1440 × 875
Device pixel ratio 2
Screen in hardware pixels 2880 × 1800
Aspect ratio 16:10
Orientation landscape
Colour depth 24 bit
Touch available no
Colour scheme preference light
Reduced motion noThe fifteen pixels between the window and the viewport are the scrollbar, and they are the reason a
100vw element can overflow a page that also has a vertical scrollbar.
Pitfalls
100vw is the viewport including the scrollbar. Which is why a full-width element on a scrolling page
can be wider than the space available. 100% on a block element, or dvw where supported, avoids it.
Device pixel ratio moves with zoom. At 150 percent browser zoom a 1x display reports 1.5. It is a measurement of the current state, not a hardware specification, and code that caches it once will be wrong after somebody zooms.
screen.width is not useful for layout. It describes the display, not the window, and a maximised window
is not the whole display either once a taskbar or dock is counted.
Touch available is not “is a phone”. Plenty of laptops report touch points. If you are choosing between a hover interaction and a tap target, the pointer media queries are the better signal.
Colour depth is almost always 24. Browsers have stopped reporting anything interesting there for privacy reasons, so it is included for completeness rather than for decisions.
innerHeight on mobile is a moving target. The URL bar and the keyboard change it, which is what the
dvh unit exists to handle. A layout pinned to 100vh will jump.
These numbers are yours. They describe this browser on this machine right now, and are not a substitute for analytics about what your audience uses.
Compatibility
Everything here is read from the browser and nothing is sent anywhere.
The interpretation is a small pure module, tested without a window: the breakpoint bands are asserted to be contiguous with no gaps, the hardware resolution is CSS pixels times the ratio, and the scrollbar figure can never go negative, which it otherwise would on a page with overlay scrollbars where the viewport measures the same or wider than the window.
Values are re-read on resize and on orientation change, so the table follows the window rather than reporting the moment the page loaded. Nothing is stored between visits.
The breakpoint names are the common set from the popular frameworks rather than any one of them, because the useful question is which of your media queries is matching, and most codebases use roughly these numbers whichever framework they came from.
Frequently asked questions
Which number should I use in a bug report?
Why is my viewport narrower than my window?
What does a device pixel ratio of 2 mean for images?
srcset and the 2x descriptor are for.Why does the height change when I scroll on my phone?
innerHeight mid-scroll. Use dvh for a full-height layout
that has to survive it.