Effective Viewport

your effective viewportlivemeasuring…

What do your visitors see when they first land on your page?

And can they use it comfortably? Type a URL and find out how your page looks in the measured space left by browser UI, docks and the on-screen keyboard.

31 devices · 320 viewport combinations
measured on real devices & simulators
runs 100% in your browser

Every screen is smaller than it claims.

So we boiled the 31 devices we track down to the smallest case per category - one card each.

Mobile · portrait360 × 514
w
Android 360 dip
h
iPhone SE 3
Mobile · landscape800 × 224
w
Android 360 dip — Landscape
h
Android 360 dip — Landscape
Tablet · portrait678 × 871
w
iPad Pro 13" / Split View (½)
h
iPad Pro 13" / Split View (½)
Tablet · landscape1194 × 681
w
iPad Pro 11" / Landscape
h
iPad Pro 11" / Landscape
Desktop · small ≤14401366 × 610
w
Chromebook 1366×768
h
Chromebook 1366×768
Desktop · medium <19201470 × 706
w
MacBook Air 13"
h
Notebook FHD @ 125%
Desktop · large 1920+1920 × 922
w
Monitor 24" FHD
h
Monitor 24" FHD
Desktop · XL 2560+2560 × 1282
w
Monitor 27" QHD
h
Monitor 27" QHD

Device list

Every tracked device and what is really left of its viewport - expand any row for the full breakdown and DevTools presets.

Test URL

Platform

Devices

Browser

Bookmarks

Dock & taskbar

Viewport

Orientation

Keyboard

Phones12

estimate
estimate
verified
verified
estimate
estimate
estimate
estimate
estimate
verified
verified
estimate

Tablets6

estimate
estimate
estimate
estimate
estimate
estimate

Laptops & desktops13

estimate
estimate
estimate
estimate
estimate
estimate
estimate
estimate
estimate
estimate
estimate
estimate
estimate

Rows prefer measured viewport scenarios. Values marked “estimate” still come from the legacy constraint fallback and have not been confirmed on a real device or simulator yet - you can help on the Measure page.

Design for references.
Test against reality.

Reference layouts are useful. They give teams a shared target. But people do not use reference layouts - they use your product inside whatever viewport the device, browser UI, dock and keyboard leave behind.

Check whether people can:

understand where they are
keep context during interaction
see feedback while they type
reach the primary action
finish the flow with the keyboard up
recover without hunting around the screen

Case 01

The landing page

Does the visitor learn what this is - without scrolling?

Image first

A full screen of visual - the visitor has to scroll just to find out what the page is about.

Message first

What it is, why it matters, where to go next - and the visual still fits.

Case 02

The product page

Big visuals sell the product, but the viewport still has to reach price, trust and the buying action.

Gallery first

The product looks polished, but price, availability and add-to-cart start below the fold.

Buyable first

The image still leads, but the decision details and primary action fit in the same view.

The step before the tools you already use

Find the broken viewport fast. Then inspect, verify and automate the fix with the tools your team already trusts.

01
Chrome DevTools
Feed it better presets
Copy a measured layout viewport preset, then inspect the page in DevTools.
02
Real devices & simulators
Prioritize hardware time
Run the wide audit here first, share the broken viewport as a link, then confirm the fix on a real device or device cloud.
03
Playwright / Cypress screenshots
Turn failures into regression tests
Use the dataset as source material for screenshot tests that assert important elements stay visible in real effective viewports.

Real traffic

Your analytics tracks screens. Your users experience viewports.

Effective Viewport shows what can happen. Production analytics can tell you whether it actually hurts: which usable-space constraints your audience lands in, and whether those constraints correlate with broken flows, abandoned forms or conversion drops.

The bucket is not the insight. The insight is what happens inside that bucket.

Bucket the pressure, not the device
Group usable width and height into coarse constraints: narrow phone, severe fold, desktop-short.
Measure a real question
Does conversion drop, does the form fail, does the modal become unusable in that bucket?
Connect it to outcomes
Join pressure buckets with conversion, abandonment, rage clicks, scroll depth and flow completion.

Example pressure buckets

Do not bucket screen resolutions into another 1366x768 report. Bucket the constraint the interface is under, then compare it with outcomes.

Read both viewports straight from the browser - no library required. The layout viewport is what CSS lays out against; the visual viewport is what is actually visible after pinch-zoom or once the on-screen keyboard opens.

const layout = {
  width: document.documentElement.clientWidth,
  height: document.documentElement.clientHeight,
};

const visual = window.visualViewport
  ? {
      width: Math.round(window.visualViewport.width),
      height: Math.round(window.visualViewport.height),
    }
  : null;

Then bucket the tightest visible space and send the bands, never the raw numbers:

Signal	Example buckets	Question it answers
usable width	`<360 / 360-389 / 390-429 / 430-767 / 768-1023 / 1024+`	Does the layout, nav or CTA physically fit?
usable height	`<520 / 520-599 / 600-699 / 700-899 / 900+`	How much above-the-fold pressure is the interface under?
viewport source	`layoutViewport / visualViewport`	Layout space versus the visible space after zoom or keyboard changes.
context	`page_load / input_focus / modal_open / checkout_step`	The moment where the UI has to work, not a generic device demographic.
outcome	`converted / abandoned / scrolled / rage_clicked`	The behavior that turns the bucket into an actual product insight.

{
  "event": "effective_viewport_seen",
  "width_bucket": "390-429",
  "height_bucket": "<520",
  "viewport_source": "visualViewport",
  "context": "checkout_step"
}

Frequently asked questions

I entered my URL, but the previews stay on the placeholder or show an error.

That's your site protecting itself, and it's the correct behavior: pages that send X-Frame-Options or a CSP frame-ancestors header refuse to be embedded in iframes on other sites - the standard defense against clickjacking. Everything here runs in your browser, so there is deliberately no server-side proxy working around it. Two ways to test anyway:

Point it at your local dev server - type http://localhost:3000 (or whatever port you use). Dev servers usually don't send those headers, so this just works.
Allowlist this origin on staging - add it to your frame-ancestors CSP directive there. (X-Frame-Options can't allowlist; that needs CSP.) Keep production locked down.

Why are these numbers smaller than the device resolution?

Because the spec sheet is not the space your page gets. Device resolutions are physical pixels; web layouts run in CSS pixels. An iPhone 15 has a 1179 × 2556 physical display, but the page starts from a 393 × 852 CSS-pixel screen. The layout viewport is what CSS and media queries actually see; the visual viewport is tracked separately for overlays such as the native keyboard.

How accurate are the numbers?

Every value carries its source. Numbers marked verified were measured on hardware or a reviewed real-device simulator run. Numbers marked estimate come from documentation, screenshots, and fallback chrome data until someone submits a real measurement. Treat estimates as a defensive minimum with default OS settings - and if you have one of those devices nearby, submitting a one-minute measurement helps improve the dataset for everyone.

Where does the URL I type get sent?

Nowhere. The whole tool runs in your browser - the URL is loaded straight into the preview iframes on your machine and never touches a server of ours. It only appears in your address bar so you can share the exact view with a colleague as a link.

About the project

Effective Viewport grew out of years of client work - deciding what has to fit above the fold, and whether the page stays usable when toolbars, docks and on-screen keyboards change what visitors can actually see. I got tired of booting simulators for every viewport, so I built one place to test a URL across common and tricky devices.

What do your visitors see when they first land on your page?

Phones12

Tablets6

Laptops & desktops13

Chrome DevTools

Feed it better presets

Real devices & simulators

Prioritize hardware time

Playwright / Cypress screenshots

Turn failures into regression tests

Your analytics tracks screens. Your users experience viewports.

Bucket the pressure, not the device

Measure a real question

Connect it to outcomes

About the project