| Metric | Value | Copy |
|---|---|---|
| {{ row.key }} | {{ row.value }} |
| Lane | Min width | Viewport | Screen | Use |
|---|---|---|---|---|
| {{ row.lane }} | {{ row.threshold }} |
{{ row.viewportStatus }}
{{ row.viewportDetail }}
|
{{ row.screenStatus }}
{{ row.screenDetail }}
|
{{ row.use }} |
{{ handoffSnippet }}
| Target | Pixels | MP | Use |
|---|---|---|---|
| {{ row.target }} | {{ row.pixels }} | {{ row.megapixels }} | {{ row.use }} |
Screen resolution is the pixel size a display reports for its usable screen, while viewport size is the pixel area your page can actually draw into inside the browser window. Those numbers matter because layout bugs usually happen in the viewport, but sharpness and density questions depend on the relationship between CSS pixels, device pixels, and physical screen size. This tool reads the current browser environment and turns those pieces into a practical snapshot.
At a glance it reports screen width and height, viewport width and height, device pixel ratio, color depth, orientation, and a simplified aspect ratio. If you also provide the display diagonal in inches, it estimates physical width, physical height, and pixel density so you can compare how tightly packed the display really is.
That makes the tool useful for responsive QA, front-end debugging, hardware comparisons, and documentation work. A designer checking a narrow phone layout cares more about the viewport lane than the full screen size, while someone comparing two laptops may care more about density and physical dimensions.
The numbers still need context. Browser chrome, zoom, operating-system scaling, split view, and rotation can all change what the page sees. A screen can report one set of values while the current page gets meaningfully less space.
It is also not a calibration or panel-quality instrument. The tool does not measure brightness, gamut, HDR behavior, refresh rate, or true panel dimensions from hardware metadata. It only works with what the browser exposes, then derives a few estimates from that data.
Use the summary badges first. They give you the current screen size, viewport size, device pixel ratio, and orientation in one line, which is often enough to explain why a layout looks different from what you expected. If the viewport is much smaller than the screen, you are usually looking at browser chrome, window sizing, or mobile interface controls taking space away from the page.
Leave the diagonal blank unless you actually want physical estimates. Without it, the tool still tells you how much CSS-pixel space is available and which breakpoint lanes fit right now. Add the diagonal only when you need estimated inches and pixel density.
The layout readiness tab is deliberately practical rather than exhaustive. It classifies the current viewport as phone, tablet, laptop, or desktop, marks the orientation as landscape-first or portrait-first, labels pixel density in plain language, and then checks whether common viewport lanes from 320 to 1024 pixels fit at the moment.
If you are comparing setups, capture both the display metrics and the JSON snapshot. That gives you a shareable record instead of relying on memory after you resize a window or rotate a device.
| Output group | What it answers | Typical use |
|---|---|---|
| Display Metrics | What the browser reports for screen, viewport, DPR, color depth, orientation, and aspect ratio | Debugging layout behavior and documenting device state |
| Layout Readiness | Whether common responsive lanes currently fit | Breakpoint checks and quick responsive QA |
| JSON | A structured snapshot of inputs, raw metrics, derived estimates, warnings, and lane checks | Sharing, record-keeping, and automation-friendly copy/paste |
The tool reads two different pixel spaces. Screen width and height come from the browser's window.screen object and represent screen dimensions in CSS pixels. Viewport width and height come from window.innerWidth and window.innerHeight, which represent the layout viewport inside the current browser window.
Device pixel ratio, or DPR, is the bridge between CSS pixels and hardware pixels. The browser reports how many physical device pixels are being used to draw one CSS pixel on the current display. That matters because the screen dimensions alone are not enough to estimate density. The tool multiplies screen width and height by DPR before calculating the diagonal in pixels.
Orientation is taken from the screen orientation API when available, then reduced to a simple landscape or portrait label. Aspect ratio is derived by reducing the reported screen width and height with the greatest common divisor, so a screen that reports 1920 by 1080 becomes 16:9.
When you provide a diagonal in inches, the app treats that as the physical diagonal and estimates pixel density with plain geometry. Estimated width and height in inches are then derived from the density result.
| Metric | Meaning | Type | Source |
|---|---|---|---|
| Screen width and height | Reported screen size in CSS pixels | integer | Observed from window.screen |
| Viewport width and height | Current layout viewport inside the browser window | integer | Observed from window.innerWidth and window.innerHeight |
| Device pixel ratio | Physical-to-CSS pixel ratio for the current display context | float | Observed from window.devicePixelRatio |
| Color depth | Reported screen color depth in bits | integer | Observed from screen.colorDepth |
| Aspect ratio | Reduced whole-number ratio of screen width to height | string | Derived |
| Estimated width, height, and PPI | Physical-size estimates based on the entered diagonal | float | Derived when diagonal is greater than zero |
Warnings are intentionally narrow. The tool flags diagonals under 2 inches, diagonals above 120 inches, estimated density below 50 pixels per inch, and estimated density above 1000 pixels per inch. Those checks are not hardware certification. They are simple prompts to recheck units, scaling, or the diagonal entry when the estimate looks implausible.
Layout readiness uses the current viewport width, not the full screen width. It classifies the viewport as Phone below 768 pixels, Tablet from 768 to 991, Laptop from 992 to 1279, and Desktop at 1280 or wider. It then reports whether the common lanes 320, 375, 768, and 1024 pixels fit without widening the viewport.
All calculations happen in the browser. Clipboard actions and file downloads occur only when you click the corresponding buttons, and the exported JSON includes the same input, observed metrics, derived estimates, warnings, and readiness rows shown on screen.
If you are debugging a layout issue, resize the window or rotate the device and watch how the viewport and readiness rows change. That often explains behavior faster than looking at screen resolution alone.
Screen and viewport answer different questions. Screen resolution tells you the broader display context the browser reports. Viewport size tells you how much room your page has right now. For responsive work, viewport usually matters more.
DPR and estimated PPI also answer different questions. DPR tells you how CSS pixels are being mapped onto hardware pixels in the current browser context. Estimated PPI tries to describe how tightly packed the display is physically, but only after you supply a believable diagonal.
Color depth should be read cautiously. Browsers often report broad compatibility values such as 24 bits, so the number is useful for rough environment awareness, not for judging display quality or color accuracy.
If the numbers look wrong, first check zoom, display scaling, window state, and whether an external monitor is active. Those factors change the browser's view of the environment more often than users expect.
Compact laptop example. If a display reports 1920 by 1080, the current browser window has a 1536 by 864 viewport, DPR is 2, and you enter a 13.3-inch diagonal, the tool estimates a density a little above 330 pixels per inch. That is a good example of a display that is physically sharp while still giving the page less viewport space than the full screen dimensions suggest.
Responsive lane check. If the viewport is 390 pixels wide in portrait orientation, the 320 and 375 lanes fit now, but the 768 and 1024 lanes do not. That tells you a phone layout should be active even if the underlying screen hardware is dense.
Suspicious density warning. If you enter a 1.5-inch diagonal for a desktop monitor and the tool flags the value as unusually small, the issue is probably the input unit rather than the display. The warning is there to catch exactly that kind of mismatch.
Viewport size reflects the page area inside the current browser window. Toolbars, tabs, side panels, mobile browser controls, and window resizing can make it smaller than the full reported screen.
It can affect DPR and the effective viewport context, so repeat comparisons are best done with the same zoom and scaling settings.
Leave it blank. The tool still reports the observed screen, viewport, orientation, aspect ratio, and readiness checks without any physical-size estimate.
No measurements are sent by this package for calculation. The page reads browser-exposed values locally, and export actions only happen when you trigger copy or download.
No. It is a derived estimate based on the browser-reported dimensions, the current DPR, and the diagonal you provide.