Browser Window Size Checker
Live-view your browser viewport size, screen specifications, and responsive breakpoints in real time.
Simulated Viewports Preview
Compare standard viewport sizes with your current screen size. Select a preset device to see how it scales relative to your browser.
Viewport Coverage
Resize Event Logger
Live TrackerResize the window to populate the log history. (Pause status is OFF).
How the Browser Window Size Checker works
This tool reads window.innerWidth and window.innerHeightto show your browser window's viewport size in CSS pixels, and window.screen.width / heightfor your monitor's full screen resolution. The Device Pixel Ratio (window.devicePixelRatio) tells you how many physical screen pixels map to a single CSS pixel — on a standard display it is 1x, while Retina/HiDPI displays are typically 2x or 3x. Multiplying window size by DPR gives the physical pixel dimensions actually being rendered by the display hardware. All values update live as you resize the window, so it's useful for checking how a layout behaves at specific breakpoints or for confirming exact dimensions before taking a screenshot.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Reading the live window and viewport size while resizing.
- Finding the exact width at which a layout breaks.
- Checking the device pixel ratio on an unfamiliar machine.
- Comparing the window size against the screen resolution.
- Confirming a breakpoint's boundary against the reported width.
Frequently Asked Questions
- What is the difference between the viewport and the screen?
- The viewport is `window.innerWidth`/`innerHeight` — the area your page can draw in, excluding browser chrome. The screen is the whole display. CSS media queries respond to the viewport, so that is the number that decides which breakpoint applies.
- What does the device pixel ratio change?
- How many physical pixels a CSS pixel covers. At a DPR of 3 a 393px-wide viewport is 1179 real pixels, which is why an image intended to look sharp there needs to be around three times its CSS size.
- Which breakpoints does it report against?
- The default Tailwind scale — 640, 768, 1024, 1280 and 1536 pixels. If your project defines its own, treat the label as a reference point and read the raw width, which is what your own media queries will see.
- Why does the resize log ignore small changes?
- Because a drag fires a resize event per frame and would flood the list with one-pixel rows. Only changes above the threshold are recorded, which keeps the log to the sizes you actually stopped at.
- Why does the height jump on mobile?
- Because the address bar hides and shows as you scroll, changing the viewport height mid-session. This is exactly why `100vh` overflows on phones, and why `100dvh` and the `visualViewport` API exist.
- Does the device list resize my window?
- No — browsers do not let a page resize a window it did not open. The preset dimensions are shown for comparison against your current viewport; your browser's own device-emulation mode is what actually changes the rendering size.
Common errors and gotchas
- Confusing screen resolution with viewport size, which differ by chrome, zoom and pixel ratio.
- Forgetting a visible scrollbar reduces the viewport width, which is a classic one-pixel bug.
- Testing at a browser zoom other than 100%, which changes the reported CSS width.
- Assuming an emulator reports the same values as the device, particularly the pixel ratio.
- Reading the value once rather than while resizing, and missing the transition.