Current Screen Resolution
{{ screenWidth }} x {{ screenHeight }}
Viewport {{ viewportWidth }} x {{ viewportHeight }} CSS px inside available screen {{ screenAvailWidth }} x {{ screenAvailHeight }}.
{{ selectedBreakpointSet.summary }} Viewport lane: {{ viewportLane.label }} DPR {{ formattedDevicePixelRatio }} {{ viewportShareBadge }} {{ physicalDensityBadgeText }}
Screen resolution inputs
{{ selectedBreakpointSet.helper }}
{{ diagonalHelperText }}
Metric Value Copy
{{ row.key }} {{ row.value }}
Lane Min width Viewport Screen Use Copy
{{ row.label }} {{ row.value }} {{ row.value }} Current reading {{ row.detail }}
{{ row.label }} {{ row.value }} {{ row.value }} Action queue {{ row.detail }}
{{ row.lane }} {{ row.threshold }} {{ row.viewportStatus }}
{{ row.viewportDetail }}
{{ row.screenStatus }}
{{ row.screenDetail }}
{{ row.use }}
Media-query starter — Handoff Responsive work {{ handoffSnippet }}
Signal Value Reading Detail Copy
{{ row.label }} {{ row.value }} {{ row.value }} {{ row.detail }}
Target Pixels MP Use Copy
{{ row.target }} {{ row.pixels }} {{ row.megapixels }} {{ row.use }}

                    
Customize
Advanced
:

Introduction

Screen resolution sounds like one clean number, but a browser actually works with several related measurements. A display can expose a full screen size, the operating system can reserve part of that space for docks or taskbars, and the browser window can carve out a smaller viewport inside what remains. Those layers explain why a site may look like a phone layout on a large monitor, or why two devices with similar headline resolutions can feel very different in practice.

CSS pixels add another layer of abstraction. Web layouts are usually measured in CSS pixels, not in raw hardware dots, so a 390-pixel viewport on a phone is not physically equivalent to a 390-pixel window on a desktop monitor. Device pixel ratio links those CSS pixels to the native raster surface, while a known diagonal lets the same pixel counts be turned into estimated physical width, height, and pixels per inch.

Diagram showing screen width, available width, viewport width, and the native raster surface reached through device pixel ratio.
Screen size, available screen size, viewport size, and native pixel surface answer different questions. A diagonal input adds estimated physical size and density.

That difference matters in several everyday cases. Responsive breakpoints care about viewport width, not the full display. Screenshot and mockup work care about the device-pixel surface behind the viewport. Hardware comparisons care about density and physical size, not just about whether two screens both say 1920 x 1080.

The readings also have clear boundaries. Browser APIs do not tell you panel brightness, refresh rate, HDR support, color gamut, or guaranteed factory dimensions. Zoom, operating-system scaling, rotation, and moving a window between displays can all change what the page reports, sometimes immediately.

Technical Details

Web layout measurements are generally expressed in CSS pixels, a reference unit used for layout and media queries rather than a direct count of physical subpixels on the panel. Screen width and height describe the full display area the browser exposes. Available width and height remove space already claimed by operating-system interface elements. Viewport width and height describe the actual page area inside the current browser window, which is why viewport size is the number that most closely predicts responsive behavior.

Device pixel ratio (DPR) connects that layout space to the native raster surface. A viewport that is 1280 x 800 in CSS pixels becomes 2560 x 1600 device pixels at DPR 2. Fractional DPR values are especially important because they usually point to browser zoom or display scaling, which means CSS-pixel comparisons and physical-size assumptions are no longer moving in neat whole steps.

Physical density needs one more input: the real display diagonal. Once screen width, screen height, DPR, and diagonal are known, the diagonal in pixels can be estimated with the Pythagorean relationship, then converted to pixels per inch. Estimated physical width and height follow from the same density value. Aspect ratio is simpler: it is just the reduced relationship between screen width and screen height, such as 1920 x 1080 becoming 16:9.

dpx = (w×dpr)2 + (h×dpr)2 ppi = dpxdin win = w×dprppi hin = h×dprppi
Breakpoint guides available in the screen resolution audit
Guide Lane thresholds Best fit
Common device widths 320, 375, 390, 414, 768, 1024, 1280, 1440 px General responsive checks when you want common phone, tablet, laptop, and desktop lanes without assuming one framework.
Bootstrap 5 grid xs 0, sm 576, md 768, lg 992, xl 1200, xxl 1400 px Audits against Bootstrap's default min-width breakpoints.
Tailwind default base 0, sm 640, md 768, lg 1024, xl 1280, 2xl 1536 px Audits against Tailwind's default responsive breakpoints.
Interpretation and warning thresholds used by the screen resolution check
Rule Threshold used here Why it matters
Viewport wider than screen Viewport width greater than screen width by more than 2 px Hints that zoom, scaling, or multi-display reporting is distorting the simple screen-to-window comparison.
Large screen-to-viewport gap Screen width minus viewport width of at least 240 px Shows that the browser window, not the display itself, is probably driving the active breakpoint.
Very small or very large diagonal Below 2 in or above 120 in Catches unit mistakes before they contaminate estimated size and density.
Estimated density outlier Below 50 ppi or above 1000 ppi Signals that the diagonal entry or the surrounding scaling assumptions should be rechecked.
Export scale recommendation 3x at DPR 2.5 or higher, 2x at DPR 1.5 or higher, otherwise 1x Turns the current raster density into a practical default for screenshot and mockup work.

Because these values come from the current browser context, they update as the window is resized, the device rotates, or the page moves between displays. That is a feature for troubleshooting, but it also means comparisons only make sense when zoom, scaling, and window state are kept stable across runs.

Everyday Use & Decision Guide

For most responsive checks, leave the diagonal blank and keep the guide on Common device widths first. That gives a quick answer to the question that usually matters most: which lane fits the current viewport right now, and which lanes only fit the full screen in theory. If you are auditing a Bootstrap or Tailwind build, switch the guide so the audit table lines up with the framework defaults instead of a generic device ladder.

The four result areas each answer a different job, so it is worth using the one that matches the decision in front of you rather than reading everything at once.

  • Display Metrics is the raw measurement view for screen size, available screen, viewport, device-pixel dimensions, width share, aspect ratio, color depth, and any physical estimate from the diagonal.
  • Breakpoint Audit is the best place to explain a layout mismatch because it separates Viewport lane from Screen lane, names the Next breakpoint, and adds a Constraint signal plus an Action queue.
  • Capture Targets is the practical tab for screenshot planning because it converts the current reading into CSS-pixel size, native device pixels, a recommended export size, and full-screen raster size.
  • JSON is the best export when another person or script needs the whole observed and derived snapshot rather than a table view.

The common wrong assumption is that a wide monitor guarantees a wide responsive layout. It does not. A browser window snapped to half a 1440-pixel display can still sit in a tablet lane, and a phone with a high DPR can still have a narrow CSS-pixel viewport. The audit makes that split visible by showing whether a lane fits the viewport now or only the screen as a whole.

Pause when Warnings appears or when the constraint badge shifts to Window constrained or Scaled viewport. Those states often mean browser chrome, split view, zoom, or operating-system scaling is shaping the result more than the panel itself. If the reading looks stable, copy or download only the artifact you need: CSV or DOCX from the measurement tabs, the Media-query starter snippet as CSS or TXT, or the full JSON snapshot for later comparison.

Step-by-Step Guide

  1. Load the page and let it read the current browser context. Start with the summary badges for the selected guide, current viewport lane, DPR, viewport width share, and density status.
  2. Choose the breakpoint guide that matches the job. Use Common device widths for a neutral check, or switch to Bootstrap 5 grid or Tailwind default when a framework-specific breakpoint question matters.
  3. Open Display Metrics if you need the raw screen, available-screen, viewport, aspect-ratio, color-depth, and device-pixel numbers before interpreting anything else.
  4. Open Breakpoint Audit to compare Viewport lane, Screen lane, Next breakpoint, and Constraint signal. Read the lane table when you need to know exactly how many pixels short a viewport is.
  5. Expand Advanced and enter the real diagonal only when you genuinely need estimated inches and ppi. Keep it blank for ordinary responsive debugging.
  6. Use Capture Targets, Media-query starter, or JSON only as far as the task needs, then export the matching artifact instead of retyping the values by hand.

Interpreting Results

The most important comparison is Viewport lane versus Screen lane. When both are the same, the current window and the overall display support the same breakpoint tier. When the screen lane is higher, the display could support a wider layout but the current browser window does not. That usually means the layout issue is about window state, split view, or available width rather than about the monitor's headline resolution.

Next breakpoint should be read literally. It tells you how many more CSS pixels are needed to reach the next lane in the selected guide. If that next lane already fits the full screen, widening the window may be enough. If it does not fit the full screen either, you need a different display context, a different zoom level, or a different device.

How to read common result patterns in the screen resolution check
Observed pattern What it usually means Best next check
Screen lane is higher than Viewport lane The display is wide enough for a larger layout, but the current browser window is not. Read Constraint signal and the lane table before blaming the site's breakpoint logic.
Constraint signal = Window constrained The viewport is far narrower than the reported screen width. Resize the window or exit split view, then compare the reading again.
Constraint signal = Scaled viewport Fractional DPR suggests browser zoom or operating-system scaling is active. Repeat the measurement with the same scaling settings before comparing two runs.
High DPR class without a diagonal The raster surface is dense, but physical density is still unknown. Use the native-pixel and recommended-export rows for screenshot work, not for hardware-grade ppi claims.
Very low or very high estimated ppi The diagonal entry or the surrounding scaling assumptions are probably wrong. Check the unit, the diagonal value, and whether zoom or scaling changed the context.
Recommended export = 2x or 3x The current display context can support a denser screenshot or mockup export than plain CSS pixels. Use that target as a practical default, then fall back to native viewport pixels if exact capture is more important.

DPR and ppi should not be treated as interchangeable. DPR describes how CSS pixels map to the current device-pixel surface. PPI tries to describe physical density, which only becomes meaningful after a believable diagonal is supplied. A display can have a high DPR in the browser while its true physical density remains unknown.

Color depth is also a context clue, not a display-grade verdict. Browsers commonly report broad compatibility values such as 24 bits, so that field is useful for environment awareness and bug reports, not for ranking panel quality.

Worked Examples

A wide monitor with a narrow working window

Suppose the screen is 1440 px wide, but the browser window only gives the page a 720 px viewport. The screen can support several desktop lanes, yet the active viewport is still below 768 px. That explains why a site may stay in a tablet or compact layout on a monitor that sounds much larger on paper.

Checking a Bootstrap breakpoint handoff

Switch the guide to Bootstrap 5 grid and imagine a viewport of 980 px. The audit will still fit md, but it is 12 px short of lg at 992 px. That is a much more useful answer for a layout bug than simply saying the screen is around 1000 pixels wide.

Planning a phone screenshot export

A phone viewport of 390 x 844 with DPR 3 has a native raster surface of 1170 x 2532. The page treats that as a 3x export candidate, so the Capture Targets tab becomes a quick handoff for screenshot markup or review decks without manually multiplying anything.

Catching a bad diagonal entry

If a desktop display is entered as 27 cm instead of 27 in, the estimated ppi can shoot far above what the panel is likely to be. That is the point of the diagonal and ppi warnings: they catch unit mistakes before the physical-size story starts looking more precise than it really is.

FAQ:

Why does my viewport size not match my screen resolution?

Viewport size is the page area inside the current browser window. Tabs, toolbars, side panels, split view, and ordinary window resizing can make it much smaller than the full reported screen.

Does browser zoom affect the reading?

Yes. Zoom and operating-system scaling often show up as a fractional DPR and can change how CSS pixels relate to the device-pixel surface.

What is the difference between DPR and ppi?

DPR is the browser's current mapping between CSS pixels and device pixels. PPI is a physical-density estimate that only becomes available when you provide a believable display diagonal.

Do I need to know my monitor size to use the page?

No. The diagonal is optional. Leave it blank when you only need screen, viewport, breakpoint, and raster-surface information.

Which breakpoint guide should I pick?

Use Common device widths for a neutral responsive check. Switch to Bootstrap 5 grid or Tailwind default when you want the audit table to match those framework defaults.

Does the page upload my display data?

No. The measurements and derived values are calculated in the browser, and copy or download actions only happen when you trigger them.

Glossary:

CSS pixel
The reference unit used for web layout and media queries.
Available screen
The reported screen area after space reserved by the operating system is removed.
Viewport
The visible layout area inside the current browser window.
Device pixel ratio
The multiplier that links CSS pixels to the native device-pixel surface.
PPI
Pixels per inch, used here as an estimate of physical display density.
Breakpoint lane
A named minimum-width tier used to judge which responsive layout range currently fits.
Aspect ratio
The reduced width-to-height relationship of the reported screen, such as 16:9.

References: