Responsive Design Tester

Straight answers

How to test a site

1. Paste the address. Just the domain is fine — example.com becomes https://example.com automatically. Local servers work too: type localhost:3000 and it is fetched from your own machine.
2. Pick a device. The list is grouped into phones, tablets, and laptops and desktops, and every entry shows its real CSS viewport size. If the device you need is missing, type any width and height into the custom fields.
3. Rotate and zoom. Rotate swaps width and height, which is the fastest way to catch the landscape bugs nobody tests for. Zoom is purely visual — the page inside still believes it is the full device width, so scaling to 50% to fit a laptop screen does not change a single media query.
4. Compare. Tick Compare devices to line up to six viewports next to each other. This is where a broken breakpoint becomes obvious: the layout that works at 390 and at 1440 is often the one that falls apart at 768.
5. Share what you found. Copy share link produces a URL carrying the site, device and orientation, so a colleague opens the exact view you are looking at.

Testing markup you have not deployed yet

Switch to Paste HTML and drop in a full document or a fragment. It renders in the same device frames without needing a server, a tunnel or a deploy — useful for checking an email template, a component, or a layout you are still writing. This mode never hits the framing wall, because nothing is being fetched from another origin.

The pasted markup runs in a sandboxed frame with its own opaque origin. Its scripts execute so you can test interactive components, but it cannot read this page, its storage or its cookies.

Device viewport sizes reference

These are CSS viewport widths — the number a media query actually compares against — not panel resolutions. The device pixel ratio is the multiplier between the two, and it decides which image a srcset serves.

The readout above the preview also names the Tailwind and Bootstrap breakpoint the current width falls into, so you can tell at a glance whether you are testing the md layout or the lg one instead of doing the arithmetic in your head.

What a viewport preview can and cannot tell you

A device preview is a layout instrument. Set the width to 390 pixels and the page inside genuinely believes it is 390 pixels wide: @media (max-width: 480px) matches, container queries resolve, vw units compute against the real number, and a grid that was told to collapse below md collapses. That covers the large majority of responsive bugs, and it catches them in seconds rather than after a deploy.

What it genuinely catches

• Horizontal overflow. The single most common mobile bug: one element with a fixed width or a stubborn min-width wider than the screen, and the whole page scrolls sideways. At a real narrow viewport it is immediately visible.
• Breakpoint gaps. Layouts are usually tested at phone width and desktop width. The failures hide in between — around 768 and 1024, where a three-column grid has not yet collapsed but no longer fits.
• Landscape. Rotate a phone and the viewport becomes short rather than narrow. Anything relying on 100vh, or a sticky header plus a sticky footer, tends to break here first.
• Text and tap targets. Copy that reflows to nine words per line, or buttons that end up too small or too close together, show up at the real width.
• Foldables and small phones. 344 pixels on a closed Z Flip and 768 on an open Z Fold are both genuinely awkward, and almost nobody tests them.

What it cannot do — and why

Being clear about the limits is the difference between a useful tool and a misleading one:

• It is not Safari on iOS. The preview uses your own browser engine. A rendering bug specific to WebKit, or to a particular Android WebView, will not reproduce here. Nothing running inside Chrome can genuinely emulate another engine.
• Touch is not simulated. You are still using a mouse. Hover states, :active behaviour, momentum scrolling and gesture handling all behave like a desktop.
• Performance is your machine's. The page loads over your connection with your CPU. It says nothing about how it will feel on a mid-range phone on a slow network.
• Screenshots are impossible. The same-origin policy prevents this page from reading the pixels inside a cross-origin frame. Any browser-only tool offering to screenshot an arbitrary site is doing it on a server. Your operating system's screenshot shortcut works fine.

Treat it as the fast first pass that catches most problems, then confirm on real hardware — which is exactly what the QR code button is for.

Why some sites refuse to load

If the preview stays blank, the site is almost certainly sending one of these:

• X-Frame-Options: DENY or SAMEORIGIN
• Content-Security-Policy: frame-ancestors 'none'

Both exist to prevent clickjacking — an attacker framing a real banking page invisibly over their own buttons. The browser enforces the refusal, and there is no client-side trick that gets around it; that is the entire point of the header. Google, Facebook, most banks, GitHub and X all set it.

Tools that do preview those sites are running a server-side proxy: their backend fetches the page, strips the header, and serves you a copy. That works, but it means the URL and every response pass through somebody else's machine. This tool has no server at all, so it takes the honest route instead and gives you two things that work on any site:

• Open at this size launches a genuine browser window at the exact device dimensions. A window is a top-level browsing context, so framing headers simply do not apply — every site opens.
• QR code puts the address on the phone in your hand, which is the only truly authoritative test anyway.

Frequently asked questions

Related tools