viewport vs screen resolution
screen.width and screen.height describe the entire monitor, but no CSS media query reads those values to decide a breakpoint: the real driver of responsive layout is window.innerWidth, the actual viewport where the page is drawn after subtracting the browser chrome. This page isolates the two numbers so you stop confusing physical resolution with usable area.
Only when the window fills the entire screen does innerWidth approach screen.width, and even then it still subtracts any fixed operating system taskbar.
Docking the DevTools panel to the side shrinks the viewport available to the page by exactly the panel width, triggering smaller breakpoints even without resizing the browser window itself.
Operating system split view is the most common reason a user sees a site mobile layout on a large monitor, because the reported viewport is far smaller than the monitor physical resolution.
The viewport is the visible area of the page in the browser, measured in CSS pixels. It changes when resizing the window, opening sidebars, changing zoom or rotating the device.
Because the media query is reacting to the real viewport width (window.innerWidth), not the monitor resolution: if the browser window only occupies half the screen, in a split view or side by side with another app, the viewport can fall below the mobile breakpoint even though the monitor is 4K.
No: window.innerWidth already subtracts the vertical scrollbar width whenever it is visible, so the value reflects the area truly available to the page content, unlike outerWidth, which measures the entire browser window including all of its chrome.
Yes: screen.availWidth subtracts areas reserved by the operating system, such as the Windows taskbar or the macOS dock, while screen.width reports the panel raw resolution; neither one, though, reflects the size of the browser window itself.
Only when the goal is to learn the physical monitor capability, such as choosing the maximum video resolution to offer a user; for layout, spacing and breakpoint decisions, window.innerWidth is always the correct measurement because it reflects the real space available to the content.
Measurements are read locally through browser APIs and do not uniquely identify your screen.