📱 Screen Resolution Simulator, Test a URL at Any Device Size

By Shihab Mia · Updated 2026-07-27

Website URL to test

Device preset

390 x 844 px DPR ~3x

Heads up: many sites send an X-Frame-Options or Content-Security-Policy header that blocks them from being shown inside an iframe like this one, for security reasons (it stops clickjacking). If the preview above stays blank or shows an error page, that site cannot be embedded here. Open the URL directly in your own browser and use its built-in device toolbar (Chrome/Edge DevTools: F12 then Ctrl+Shift+M) to test it at this size instead. This limitation is not a bug in this tool, it is a security feature the target site controls.

Reference: pixel dimensions and typical device pixel ratio (DPR) for each preset.

Device	CSS px (W x H)	Typical DPR

This screen resolution simulator loads any URL inside an iframe sized to a real device preset, such as iPhone 14, Galaxy S21, iPad Mini, or a custom width and height you set yourself. It reports the exact CSS pixel dimensions and typical device pixel ratio for the chosen device, and scales the preview to fit the page without changing the true size of what is being tested. It is built for a quick visual sanity check of a layout at a given size, not as a replacement for full browser developer tools.

What is the Screen Resolution Simulator?

A screen resolution simulator works by rendering a target page inside an iframe whose width and height are fixed to the CSS pixel dimensions of a chosen device, for example 390 by 844 for an iPhone 14. Because the iframe forces the browser to lay out the page as if the viewport were exactly that size, any responsive CSS media queries, flexible grids, or breakpoint-based navigation on the target page respond exactly as they would on that real device. When the frame is wider than the space available on the card, this tool shrinks it with a CSS transform so you can see the whole thing at once, and always shows the true, unshrunk pixel dimensions in the label above so the numbers you read are never affected by the on-screen scaling.

Device pixel ratio, usually abbreviated DPR, is a separate concept from CSS pixel dimensions and is worth understanding before you rely on either number. A CSS pixel is a layout unit, the one your stylesheet media queries use to decide when to switch a design between mobile and desktop layouts. A physical pixel is an actual dot on the screen. DPR is the ratio between them: an iPhone 14 has a CSS viewport of 390 by 844 but a physical screen resolution far higher than that, because its DPR is about 3, meaning each CSS pixel is drawn using roughly 3 by 3 physical pixels for sharper text and images. This is why the marketing spec sheet for a phone often quotes a resolution like 1170 by 2532, while responsive design tools and browser dev tools quote 390 by 844, the CSS pixel figure that layout code actually reacts to. Both numbers are correct, they just answer different questions, and this tool reports the CSS figure because that is what determines how a responsive layout behaves.

The honest limitation of any iframe-based simulator, including this one, is that a meaningful share of production websites intentionally block being loaded inside a frame on another domain. The two mechanisms are the X-Frame-Options response header (commonly set to SAMEORIGIN or DENY) and the newer Content-Security-Policy frame-ancestors directive, both of which exist specifically to stop clickjacking attacks where a malicious site tricks a visitor into interacting with a hidden, framed copy of a legitimate page such as a bank or login screen. When a site sends either header, browsers refuse to render its content inside a foreign iframe, and no client-side JavaScript trick can bypass that, because the restriction is enforced by the browser itself as a security boundary, not a bug in the framed page. If a preview here stays blank, shows a browser error page, or never finishes loading, the answer is almost always that the target site is protecting itself this way, not that this tool is broken.

Because of that limitation, treat this simulator as a first-pass visual check, particularly useful for pages you control that do not send those headers, or for quickly comparing how a layout reflows across several sizes side by side. For the sites that block embedding, and for pixel-perfect or interactive testing (tapping menus, testing hover states, checking touch targets), open the URL directly in your own browser and use its built-in responsive design mode, for example Chrome or Edge DevTools device toolbar (F12, then Ctrl+Shift+M), which renders the real page natively at any resolution with no framing restrictions at all.

When to use it

Getting a fast visual check of how a landing page reflows at common phone, tablet, and desktop widths before a client review.
Comparing a mobile-first design against a laptop or desktop breakpoint side by side without resizing your actual browser window.
Checking whether a specific custom width, such as a target ad unit or embed size, breaks a page layout.
Confirming the CSS pixel dimensions and typical DPR of a named device before writing a media query for it.
Sharing a quick, no-install way for a non-technical teammate to see roughly how a page looks on a phone-sized viewport.
Spot-checking your own site after a CSS change, on pages that do not send frame-blocking security headers.

How to use the Screen Resolution Simulator

Enter the full URL of the page you want to test, including https://.
Pick a device preset from the dropdown, or choose Custom size and enter your own width and height in pixels.
Click Load preview to render the page inside a frame sized to that device.
Read the exact pixel dimensions and typical device pixel ratio shown above the preview.
If the preview stays blank or shows an error, that site is blocking iframe embedding, open the URL directly in your browser and use its device toolbar instead.

Formula & method

The tool sets iframe width = preset width in CSS pixels and iframe height = preset height in CSS pixels, unchanged from the device spec. If the available card width is narrower than the preset width, a display scale factor is applied only visually: scale = min(1, available width / preset width), applied with CSS transform: scale(factor). The iframe element itself keeps its true width and height attributes at all times, so the labelled dimensions and the page layout the target site receives are never affected by the visual scale factor, only the on-screen size of the preview is.

Worked examples

You pick the iPhone 14 preset (390 x 844 CSS pixels) to preview a page, and your browser card has 320px of usable width to show the frame.

Preset width = 390, preset height = 844, this is what the iframe attributes are set to.
Available display width = 320px (narrower than 390, so the preview needs shrinking to fit).
Scale factor = min(1, 320 / 390) = min(1, 0.821) = 0.821.
Displayed on-screen size = 390 x 0.821 = 320px wide, 844 x 0.821 = 693px tall.
The dimensions label still reads "390 x 844 px" because that is the true size the target page is laid out at, only the visible box is shrunk.

Result: iframe stays 390 x 844 internally, displayed at roughly 320 x 693 on screen, label shows 390 x 844 px.

You switch to a custom size of 1920 x 1080 (Desktop preset) on a card that has 900px of usable width.

Preset width = 1920, preset height = 1080.
Available display width = 900px.
Scale factor = min(1, 900 / 1920) = min(1, 0.469) = 0.469.
Displayed on-screen size = 1920 x 0.469 = 900px wide, 1080 x 0.469 = 506px tall.
DPR for the Desktop preset is listed as 1x in the reference table, so no separate physical-pixel adjustment applies.

Result: iframe stays 1920 x 1080 internally, displayed at roughly 900 x 506 on screen, label shows 1,920 x 1,080 px.

Built-in device presets: CSS pixel dimensions and typical device pixel ratio (DPR)

Device preset	CSS pixels (W x H)	Typical DPR	Common use
iPhone SE	375 x 667	2x	Smallest common modern iPhone breakpoint
iPhone 14	390 x 844	3x	Mainstream current-generation iPhone
iPhone 14 Pro Max	430 x 932	3x	Largest current iPhone viewport
Samsung Galaxy S21	360 x 800	3x	Common Android reference width
iPad Mini	768 x 1024	2x	Small tablet, common portrait breakpoint
iPad Pro 12.9-inch	1024 x 1366	2x	Large tablet, near-laptop widths
Laptop	1366 x 768	1x	Most common laptop resolution worldwide
Desktop	1920 x 1080	1x	Standard full HD desktop monitor

Common responsive breakpoints these presets are useful for testing against

Breakpoint range	Typical label	Matching preset(s)
Up to 480px	Small mobile	iPhone SE, Galaxy S21
481px to 767px	Large mobile	iPhone 14, iPhone 14 Pro Max
768px to 1023px	Tablet	iPad Mini
1024px to 1365px	Small laptop / large tablet	iPad Pro 12.9-inch
1366px and up	Desktop	Laptop, Desktop, or a larger custom size

Common mistakes to avoid

Assuming a blank preview means the tool is broken. The most common cause of a blank or error-filled frame is the target site sending an X-Frame-Options or Content-Security-Policy header that deliberately blocks embedding, a security measure against clickjacking. This affects most banks, many SaaS dashboards, and plenty of major consumer sites. It cannot be bypassed client-side. Open the URL directly in your own browser instead.
Confusing CSS pixel dimensions with marketing resolution specs. A phone spec sheet quoting "1170 x 2532" is describing physical screen pixels, not the CSS viewport a responsive design reacts to. For layout and media-query purposes, use the CSS pixel figure (for example 390 x 844 for iPhone 14), which is what this tool and browser dev tools both report.
Treating a simulated preview as equivalent to a real device test. An iframe simulator confirms layout reflow at a given width and height, but it cannot reproduce touch gestures, native mobile browser chrome, real network conditions, or hover-versus-tap behavior differences. Use it as a fast first check, then verify anything that matters on an actual device or in full browser DevTools before shipping.
Forgetting that device pixel ratio does not change layout width. A higher DPR (like the 3x on most modern phones) affects how crisp images and text render, it does not add extra CSS pixels of usable layout space. Do not assume a 3x DPR device has three times more room for content than its listed CSS width, the layout width is what governs your breakpoints.

Glossary

CSS pixel: A device-independent layout unit used by stylesheets and media queries, distinct from a physical screen pixel.
Device pixel ratio (DPR): The ratio of physical screen pixels to CSS pixels, for example 3x means each CSS pixel is rendered using a 3 by 3 block of physical pixels.
Viewport: The visible area of a web page in the browser window, measured in CSS pixels, that responsive breakpoints are based on.
X-Frame-Options: An HTTP response header a site can send to block or restrict other pages from loading it inside an iframe, commonly used to prevent clickjacking.
Content-Security-Policy frame-ancestors: A modern, more flexible HTTP header directive that lists which origins, if any, are allowed to embed a page in a frame, replacing the older X-Frame-Options in many setups.
Responsive breakpoint: A defined viewport width at which a page's CSS switches layout, for example from a stacked mobile menu to a horizontal desktop navigation bar.

Frequently asked questions

Why is the preview blank for some websites?

That site is very likely sending an X-Frame-Options or Content-Security-Policy header that blocks it from being shown inside anyone else's iframe, including this tool. This is a deliberate security feature used to prevent clickjacking attacks, and it affects a large share of banks, logged-in dashboards, and major consumer sites. There is no client-side workaround. Open the URL directly in your own browser and use its device toolbar instead.

What is the difference between CSS pixels and the resolution listed on a phone's spec sheet?

A phone's marketing spec sheet lists its physical screen resolution, for example roughly 1170 x 2532 for an iPhone 14. Responsive web design does not use that number directly, it uses the CSS pixel viewport, which for the same phone is 390 x 844. The physical resolution divided by the CSS viewport gives the device pixel ratio, about 3x in this case. This tool always shows the CSS pixel figure because that is what your media queries respond to.

Does this replace my browser's built-in device toolbar or DevTools?

No, and it is not meant to. A simulator like this is a fast, no-setup way to see a rough layout reflow at a given size. Full browser DevTools (like Chrome or Edge's device toolbar, F12 then Ctrl+Shift+M) render the real page with no iframe restrictions, simulate touch input, throttle network speed, and let you inspect every element. Use this tool for a quick first look, and DevTools for serious testing.

What device pixel ratio should I design for?

Most current phones use a DPR of 2x or 3x, most laptops and desktop monitors still commonly use 1x, though high-DPI desktop displays are increasingly 2x. There is no single correct value to design for; instead, use responsive images (srcset) and vector graphics where possible so your design looks sharp across the whole range rather than targeting one fixed ratio.

Can I test my own localhost site with this?

Generally no. Browsers block a page served from https over a public domain from loading a plain http://localhost address inside an iframe due to mixed-content and cross-origin restrictions, and many local dev servers do not send permissive framing headers either. For local development, use your browser's own device toolbar directly against localhost instead.

Why does the preview look shrunk compared to the pixel size shown in the label?

When a device preset is wider than the space available on your screen, for example the 1920px-wide Desktop preset, the tool visually scales the frame down with a CSS transform so the whole thing fits without a huge scrollbar. The underlying iframe keeps its true width and height, so the target page is still laid out at the full, correct size, and the dimensions label reflects that true size, not the shrunk on-screen appearance.