What Is My Screen Resolution
Check screen resolution online with viewport, DPR, breakpoint audits, and capture-size exports so you can debug responsive layouts and screenshot prep faster.Current Screen Resolution
| 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 }} |
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.
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.
| 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. |
| 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 Metricsis 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 Auditis the best place to explain a layout mismatch because it separatesViewport lanefromScreen lane, names theNext breakpoint, and adds aConstraint signalplus anAction queue.Capture Targetsis 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.JSONis 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
- 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.
- Choose the breakpoint guide that matches the job. Use
Common device widthsfor a neutral check, or switch toBootstrap 5 gridorTailwind defaultwhen a framework-specific breakpoint question matters. - Open
Display Metricsif you need the raw screen, available-screen, viewport, aspect-ratio, color-depth, and device-pixel numbers before interpreting anything else. - Open
Breakpoint Auditto compareViewport lane,Screen lane,Next breakpoint, andConstraint signal. Read the lane table when you need to know exactly how many pixels short a viewport is. - Expand
Advancedand enter the real diagonal only when you genuinely need estimated inches and ppi. Keep it blank for ordinary responsive debugging. - Use
Capture Targets,Media-query starter, orJSONonly 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.
| 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:
- Screen: width property, MDN Web Docs.
- Screen: availWidth property, MDN Web Docs.
- Window: innerWidth property, MDN Web Docs.
- Window: devicePixelRatio property, MDN Web Docs.
- Screen: colorDepth property, MDN Web Docs.
- ScreenOrientation: type property, MDN Web Docs.
- <length>, MDN Web Docs.
- Breakpoints, Bootstrap.
- Responsive design, Tailwind CSS.