Viewport Size Simulator
Preview any site at real device viewport sizes in CSS pixels. Drag to resize with a live breakpoint readout, flip orientation, overlay iOS safe areas, compare phone, tablet and desktop side by side, and share the exact setup by URL.
Drag the handles on the right and bottom edges of the frame to resize live. Sizes are CSS pixels — the same units your media queries use. Current breakpoint: below sm.
About Viewport Size Simulator
The Viewport Size Simulator renders a site inside a frame sized to an exact CSS-pixel viewport, so you can see which media queries fire at 393px, 834px or 1440px without owning the hardware. It ships current device presets with device-pixel-ratio badges, approximate iOS safe-area overlays, drag handles that resize the frame live with a Tailwind breakpoint readout, orientation flip, a 1:1 toggle for pixel-exact inspection, and a side-by-side mode that renders phone, tablet and desktop at once. The important caveat is stated up front rather than hidden: many sites send X-Frame-Options or a Content-Security-Policy frame-ancestors directive that blocks embedding, and browsers deliberately give the embedding page no way to detect that — so the tool always offers a one-click fallback that opens the URL in a real browser window at the same dimensions.
Why use a Viewport Size Simulator?
Responsive bugs are almost always breakpoint bugs, and breakpoints are expressed in CSS pixels — the same unit this tool sets. Resizing your desktop browser window cannot reach 393×852, and buying a phone for every preset is not a plan. A sized frame gets you the layout answer in seconds: does the nav collapse, does the table overflow, does the sticky footer eat the content. The drag handles with a live breakpoint label also make it obvious exactly where a layout breaks, which is the part a static preset list cannot tell you. And because the tool is honest about iframe refusal, you are never left staring at a silent white box wondering whether your site is broken.
Who is it for?
Front-end developers checking breakpoints during a build, QA engineers reproducing a layout bug reported on a specific device, designers reviewing a staging URL at the sizes in their spec, agencies demonstrating responsive behaviour to clients, and technical writers or educators showing how media queries respond to viewport width. It is also useful for anyone auditing a page that must work at 320–400px, where the majority of mobile traffic actually sits.
How to use the tool
Type or paste the URL into the Website URL field and click Load (or press Enter) — an invalid or non-http(s) URL is rejected with a message instead of being silently replaced
Open Device presets and pick a phone, tablet or desktop size; each shows its CSS-pixel viewport and device-pixel-ratio badge
Or type exact Width and Height values in CSS pixels, or drag the handles on the right edge, bottom edge or bottom-right corner of the frame to resize live
Watch the readout above the frame: it shows the current size, the DPR badge and the nearest Tailwind breakpoint (sm 640, md 768, lg 1024, xl 1280, 2xl 1536)
Click the orientation button to swap width and height, and toggle Safe areas on a phone preset to overlay approximate notch and home-indicator insets
Toggle 1:1 when the frame is being scaled down — the preview then renders at one CSS pixel per pixel and scrolls instead of shrinking
Switch on Side by side to render iPhone, iPad Pro and MacBook simultaneously, each scaled to its own column
If the frame stays blank, use the Open in a real window button in the notice below the preview — it opens the same URL in a browser window at the same dimensions, where framing headers do not apply
Copy the page URL to share the exact setup: the target URL, width and height are stored as ?url=, &w= and &h= query parameters
Key Features
Honest frame-refusal handling
A refused frame still fires a load event and its location cannot be read cross-origin, so refusal is genuinely undetectable from the embedding page. Instead of pretending, the tool shows an advisory panel two seconds after load with a real-window fallback, copyable DevTools steps and an explanation of X-Frame-Options versus frame-ancestors. It is dismissible for the session.
No preview size cap
The frame renders at full size whenever it fits the available column and scales down proportionally when it does not, with a visible scale badge. A 1:1 toggle switches to pixel-exact rendering with scrolling instead of scaling.
Drag to resize with a live breakpoint label
Handles on the right edge, bottom edge and corner resize the viewport live, with a floating readout showing the exact width × height and the matching Tailwind breakpoint — the fastest way to find where a layout actually breaks.
Current device presets with DPR
iPhone SE through iPhone 16 Pro Max, Pixel 8/9, Galaxy S23/S24, iPad mini/10th gen/Pro 11 and 13, MacBook Air 13, 1080p, 1440p and 4K — each with its CSS-pixel viewport and device-pixel ratio.
Safe-area overlays
Phone presets can overlay approximate env(safe-area-inset-top/bottom) bands so you can see whether a fixed header or bottom bar would collide with the notch, Dynamic Island or home indicator.
Side-by-side comparison
One toggle renders phone, tablet and desktop frames at the same time, each scaled to its column and each with its own framing notice, so a single page load shows all three layouts.
Shareable setup
The target URL, width and height live in the query string (?url=&w=&h=) and update as you resize, so a link reproduces the exact preview for a teammate or a bug report.
Orientation flip and manual sizing
Swap width and height with one click, or type exact values — useful for reproducing a bug report that cites a specific viewport size rather than a device name.
Common Use Cases
Finding the exact width where a layout breaks
Scenario: A grid collapses badly somewhere between tablet and desktop but you do not know where.
✓ Drag the right-edge handle slowly and watch the live width and breakpoint label — the failure point is a number you can put straight into a media query.
Reproducing a device-specific bug report
Scenario: A tester reports a broken header on an iPhone 16 Pro.
✓ Select the preset (402×874), toggle Safe areas, and see immediately whether the fixed header is being overlapped by the Dynamic Island inset.
Client review of a staging site
Scenario: You need to show a client how one page behaves on phone, tablet and desktop without switching devices mid-call.
✓ Turn on Side by side, share the ?url=&w=&h= link, and all three frames render at once on their screen too.
Checking a page that refuses framing
Scenario: The preview is blank because the site sends frame-ancestors 'self'.
✓ Use Open in a real window at this size — the page opens in a genuine browser window at the same dimensions, where the header does not apply.
Verifying the small-phone floor
Scenario: A large share of mobile traffic is 360–393px wide and your design was drawn at 430px.
✓ Switch between Galaxy S23/S24 (360), iPhone SE (375) and iPhone 15/16 (393) to check that nothing overflows at the narrow end.
Viewport sizes are CSS pixels as used by media queries; device-pixel ratios and safe-area insets are published reference values and are labelled as approximate.
Sizing, scaling and measurement run entirely in your browser and nothing is proxied through Toolsana. The frame does load the target site directly from its own server, so that server sees a normal visit from your browser.
Static page — no backend dependency.
Frequently Asked Questions
How do I simulate a device viewport size?
Paste the address into the Website URL field and click Load (or press Enter). Then either pick a preset under Device presets, type exact Width and Height values in CSS pixels, or drag the handles on the right edge, bottom edge or corner of the frame. The readout above the preview shows the live size, the device-pixel-ratio badge and the nearest Tailwind breakpoint. Use the orientation button to swap width and height, 1:1 to stop the frame being scaled down, and Side by side to render phone, tablet and desktop at once. The URL updates to ?url=&w=&h= so you can share the exact setup.
Why is the preview blank for some sites?
Because the site refuses to be embedded. `X-Frame-Options: DENY` or `SAMEORIGIN`, and the modern CSP directive `Content-Security-Policy: frame-ancestors`, tell the browser not to render the page inside a frame from another origin. Most large sites — Google, Facebook, GitHub, banks, most CMS admin panels — set one of them as clickjacking protection, and it cannot be bypassed from a web page. When that happens, use the Open in a real window at this size button in the notice below the preview, or the copyable Chrome DevTools steps. On your own site you can temporarily allow framing in a development environment only.
Why can't the tool just tell me the site blocked it?
Browsers deliberately hide that. A refused frame still fires the `load` event, because the browser renders its own error document inside the frame, so there is no error signal to listen for. Reading `iframe.contentWindow.location.href` throws a `SecurityError` for every cross-origin document, whether it loaded correctly or not, so that test cannot distinguish success from refusal either. That is why this tool shows an advisory panel a couple of seconds after load rather than claiming a definitive result — and why the panel is dismissible for the session once you have read it.
Is this a substitute for testing on a real device?
No. This is a CSS-pixel layout check only. Real devices differ in touch and hover behaviour, font rendering and text-size adjustment, CPU and memory, browser engine (iOS Safari is WebKit regardless of the app), on-screen keyboards that take half the viewport, dynamic browser chrome that changes `100vh` while scrolling, and gesture handling. Use the simulator to catch breakpoint and overflow problems quickly — which is most responsive bugs — then confirm anything interaction-heavy on real hardware or a device cloud such as BrowserStack. Chrome DevTools' device mode is a good middle ground because it also emulates touch events and DPR.
What's the difference between CSS pixels and device pixels?
CSS pixels are the logical units your media queries, `width` declarations and `viewport` meta tag use. Device pixels are the physical dots on the panel. The ratio between them is `window.devicePixelRatio`. An iPhone 15 is 393×852 CSS pixels at DPR 3, which is 1179×2556 physical pixels. This tool sets CSS pixels — the design unit — and shows the DPR as a badge for reference. It cannot change your monitor's actual DPR, so `srcset`, `image-set()` and `-webkit-min-device-pixel-ratio` queries still resolve against your own display, not the simulated device.
How accurate are the safe-area overlays?
They are approximate. The overlay draws typical portrait values for `env(safe-area-inset-top)` and `env(safe-area-inset-bottom)` — around 47px on notch iPhones, 59–62px on Dynamic Island models, 34px for the home indicator, roughly 24px for Android status and gesture bars. Real values change with iOS version, orientation, whether the page is in a browser or a standalone PWA, and whether the keyboard is open. Treat the overlay as a collision check for fixed headers and bottom bars, not as a measurement. Always position real UI with the `env()` variables rather than hard-coded numbers.
Which breakpoints should I actually test?
Start with the Tailwind defaults the readout labels: sm 640, md 768, lg 1024, xl 1280, 2xl 1536. Test just below and just above each one, because the bug is almost always in the transition. Then add the real-world floor: a large share of mobile traffic is 360–393px wide, so check 360 (Galaxy S23/S24), 375 (iPhone SE) and 393 (iPhone 15/16) explicitly. For content-heavy pages, also check 820–834px, where tablet portrait often lands on the desktop layout with too little width. Dragging the handle across a range beats checking presets one at a time.
Does the site I preview know I visited it?
Yes. The sizing is pure CSS and happens in your browser, but the frame still fetches the page from its real server, exactly as a normal visit would — the server sees your IP, your user agent and a referrer. Nothing is proxied through Toolsana and no data about the page reaches us; the only state we keep is the ?url=&w=&h= query string in your address bar. Do not use this to preview URLs containing session tokens or one-time links, since they will end up in that shareable URL. For a viewport meta tag check, see the [Meta Tag Generator](/tools/meta-tag-generator/); for unit conversions, the [PX to EM/REM Converter](/tools/px-em-rem-converter/).
Technical Specifications
Supported Formats
- ✓Viewport sizing in CSS pixels, 200–4096 px per axis, via presets, numeric inputs or drag handles
- ✓Presets: iPhone SE/13/14/15/16/15-16 Plus/16 Pro/16 Pro Max, Pixel 8-9, Galaxy S23-S24, iPad mini/10th gen/Pro 11 and 13, MacBook Air 13, 1080p, 1440p, 4K
- ✓Breakpoint readout against the Tailwind defaults: sm 640, md 768, lg 1024, xl 1280, 2xl 1536
- ✓Device-pixel-ratio badges (informational — the browser's real DPR is unchanged)
- ✓Approximate env(safe-area-inset-top/bottom) overlays for phone presets
- ✓Scale-to-fit with a visible percentage badge, plus a 1:1 pixel-exact mode with scrolling
- ✓Side-by-side rendering of phone, tablet and desktop frames
- ✓Shareable state via ?url=, &w= and &h= query parameters, written with history.replaceState
- ✓Only http:// and https:// URLs are accepted; other schemes are rejected with a validation message
Limits & Performance
- •File Size: One target URL at a time (three frames in side-by-side mode); viewport sizes from 200×200 to 4096×4096 CSS px
- •Validations: URLs are parsed with the URL API; a missing scheme defaults to https, and non-http(s) schemes or malformed hosts are rejected rather than silently replaced
- •Response Time: Frame layout is instant; page load time is entirely the target site's. A frame that has not loaded after 6 seconds is flagged as a probable framing refusal
- •Browsers: All modern browsers (Chrome, Firefox, Safari, Edge). Drag resizing uses Pointer Events and works with touch and stylus
Pro Tips
- Drag the width handle slowly through a breakpoint instead of clicking presets — the exact pixel where a layout breaks is far more useful than knowing that it breaks.
- Use 1:1 mode when you need to judge type size or spacing; a scaled-down frame is fine for layout but lies about legibility.
- If the preview is blank, assume framing refusal before assuming your site is broken — confirm with the Open in a real window button.
- Check 360px before 430px: the narrow end is where overflow bugs live, and it is a large share of real mobile traffic.
- Remember that mobile browser chrome changes viewport height while scrolling, so 100vh behaviour cannot be validated in a fixed-height frame — use dvh/svh/lvh and confirm on a device.
- The DPR badge is informational: an iframe cannot change your display's real pixel ratio, so retina asset selection still follows your own monitor.
- Preview staging URLs, not links with session tokens — the URL is written into the shareable query string.
- Side-by-side mode loads the page three times; on a slow staging server, load it once at a single size first to warm any caches.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.