Viewport Size Checker — live breakpoint detector

The viewport size checker on this page reads your browser's live viewport dimensions, your screen's full resolution, your device's pixel ratio, and your current orientation, then tells you exactly which common CSS breakpoint category — mobile, tablet, laptop, or desktop — your current window falls into, updating instantly as you resize.

It exists because "what breakpoint am I actually looking at right now" is a question every front-end developer asks dozens of times a week, and the browser's own dev tools bury this information a few clicks deeper than it needs to be — Arb Digital built this as a one-glance answer.

What This Viewport Size Checker Does

The moment the page loads, the tool reads window.innerWidth and window.innerHeight (your actual viewport — the visible browser content area), window.screen.width/height (your monitor or device's full resolution), and window.devicePixelRatio (how many physical pixels the screen packs into each CSS pixel). It listens for the browser's resize event so every number updates live as you drag your browser's edge, split your screen, or rotate a phone — no refresh, no button click required. It then compares your current viewport width against a standard set of breakpoint thresholds to tell you, in plain language, whether you're currently in "mobile," "tablet," "laptop," or "desktop" territory.

How to Use the Viewport Size Checker

1. Just load the page — the live width, height, and breakpoint are already populated the instant it renders.
2. Resize your browser window and watch the width, height, and breakpoint label update automatically.
3. Check the device pixel ratio if you're debugging a blurry image or an icon that looks pixelated on a high-density screen.
4. Rotate a mobile device (or use your browser's device-toolbar simulator) to see the orientation flip between portrait and landscape.
5. Compare against the reference table below to see which real-world device category your current width lines up with.
6. Click "Refresh Now" any time if you want to force an immediate re-read without resizing.

Viewport vs Screen vs Device Pixel Ratio — What's the Difference

These three numbers are often confused, but they answer three genuinely different questions. Viewport size is the visible area of the browser window that your webpage's content actually renders into — it shrinks if you open dev tools, resize the browser, or the OS shows a taskbar, and it's the number your CSS media queries and vw/vh units are based on. Screen resolution is the full physical (or logical) resolution of the monitor or device itself, regardless of how big your browser window currently is — a 1920×1080 monitor is still 1920×1080 even if your browser only occupies half of it. Device pixel ratio (DPR) describes the relationship between CSS pixels and physical device pixels — a DPR of 2 (common on phones and Retina-class displays) means every single CSS pixel is actually rendered using a 2×2 grid of physical pixels, which is why a 100×100px CSS image needs to be at least 200×200px in source resolution to look sharp on that screen. The formal specification for how these values are defined is documented at MDN's Viewport glossary entry.

Why Breakpoints Don't Have One Universal Standard

Unlike CSS specificity or the box model, there's no official W3C-mandated set of breakpoint numbers — every design system and CSS framework (Bootstrap, Tailwind, Material Design, Foundation) picks its own thresholds based on the devices most common at the time it was built. That said, most of these systems converge on roughly the same rough zones: somewhere under 600–768px is treated as "mobile," 768–1024px as "tablet," 1024–1280px as "small laptop/desktop," and above that as "large desktop." This tool uses those widely-adopted rough zones as a sensible default, and knowing which zone you're currently in is far more useful in practice than obsessing over the exact pixel where one framework's breakpoint begins and another's ends.

Why This Matters for Responsive Design and Testing

A huge share of layout bugs only show up in the "in-between" widths that nobody explicitly designed for — a foldable phone unfolded to 700px, a small laptop at 1152px, an iPad in split-screen at 500px. Actually seeing your live numbers while you test — rather than guessing based on a device name — makes it far easier to catch these bugs early, and it's especially useful when you're debugging a clamp()-based fluid type system, a CSS Grid layout with breakpoint-dependent column counts, or a navigation menu that needs to collapse into a hamburger icon at a specific width.

Media Queries: min-width vs max-width and Why the Direction Matters

Once you know your current viewport width, the next question is usually how to write the media query that targets it — and there's a meaningful design decision hiding in whether you write it as min-width or max-width. A "mobile-first" approach writes your base styles for the smallest screen, then layers on @media (min-width: 768px) rules that add complexity as the viewport grows — this tends to produce simpler, more maintainable CSS since you're only ever adding rules, never fighting to override ones written for a bigger screen. A "desktop-first" approach does the reverse, styling for the largest screen first and using max-width queries to peel functionality away for smaller viewports — historically more common, but increasingly considered the harder-to-maintain approach as mobile traffic overtook desktop for most sites. Whichever direction you choose, the numbers this checker reports are exactly what your media queries are being evaluated against — if you're debugging why a rule "isn't firing," the live viewport width shown here is the first number to compare against your breakpoint's threshold.

Container Queries: A Newer Complement to Viewport-Based Breakpoints

Traditional media queries respond only to the overall browser viewport, which works fine for full-page layout changes but breaks down for reusable components that need to adapt based on the space available to them specifically — a card component might sit in a wide single-column layout on one page and a narrow three-column grid on another, needing different internal styling in each case despite the viewport being identical. CSS container queries, now supported in all major modern browsers, solve this by letting a component respond to its own containing element's width rather than the page's viewport width. This checker reports viewport-level numbers rather than any particular container's size, since "the viewport" is a single well-defined global value while a container's size is specific to wherever that component happens to be placed — but understanding the viewport clearly first is still the right foundation before layering container queries on top for component-level responsiveness.

• Confirm the exact pixel width where your navigation menu should collapse.
• Check whether a "mobile-only" component is still visible at a tablet width it shouldn't render at.
• Debug blurry images by checking device pixel ratio against your exported image resolution.
• Verify your fluid typography (from a tool like our CSS Clamp Generator) looks right at your actual current width, not just a simulated one.

How Browser Zoom and OS Scaling Interact With These Numbers

Two settings quietly change every number this tool reports without changing your physical hardware at all: browser zoom and operating-system display scaling. Zooming a browser page in or out effectively changes how many CSS pixels fit in the same physical window, which shifts window.innerWidth even though nothing about your monitor changed — this is intentional, since zoom is meant to make content appear larger or smaller relative to the viewport. OS-level display scaling (the "150% scaling" option common on Windows high-DPI laptops, or the equivalent on macOS) works differently: it changes the effective device pixel ratio the browser reports, which is why the same physical 1920×1080 panel can report itself as an "effective" 1280×720 viewport once scaling is factored in. Neither of these is a bug in this tool or in your browser — they're exactly why relying on a live reading, rather than trusting a device's marketed resolution, is the more reliable way to debug a layout issue.

Using This Tool Alongside Browser DevTools Device Emulation

Chrome, Firefox, Safari, and Edge all ship a device-toolbar or responsive-design mode that simulates common phone and tablet sizes, but the simulated numbers they show aren't always identical to what a real device reports, particularly for device pixel ratio and safe-area insets on notched phones. This checker is a useful second opinion: load it inside your browser's device emulator to confirm the simulated viewport matches what you expect, and then — whenever possible — load it on an actual physical device too. Real hardware occasionally reports a slightly different effective viewport than its emulated equivalent, especially around browser chrome (address bars that hide on scroll, safe-area notches, and split-screen multitasking on tablets), and catching that difference before launch is far cheaper than a bug report from a real user later.

Common Mistakes to Avoid

• Confusing screen resolution with viewport size. Your monitor being 4K doesn't mean your browser window — and therefore your webpage's viewport — is anywhere near that wide; users routinely browse in a partial-width window.
• Ignoring device pixel ratio when exporting images. An image sized exactly to its CSS display dimensions will look soft or blurry on any DPR-2 screen; export at 2x (or use responsive srcset) for crisp results.
• Designing only for named devices. "iPhone width" and "iPad width" change with every new hardware generation — design around breakpoint ranges and fluid layouts, not a fixed list of device models.
• Forgetting that scrollbars affect viewport width. On some operating systems and browsers, a visible vertical scrollbar subtracts a small amount from the usable viewport width, which can matter for pixel-perfect layouts.
• Testing only in portrait or only in landscape. Real users rotate their devices constantly — always check both orientations, especially for tablets where the layout difference is often significant.

Related Free Tools From Arb Digital

Pair this checker with the CSS Clamp Generator to build fluid sizing that adapts to whatever width this tool reports, the CSS Grid Generator and CSS Flexbox Generator for breakpoint-aware layouts, and the CSS Specificity Calculator for debugging styles that only misbehave at certain widths. Browse everything in our free online tools hub.

Frequently Asked Questions