b2KIT

Responsive Design Checker

Preview website layouts across mobile, tablet, and desktop breakpoints with resizable iframe testing.

Tested tool guide Tested browser tools Checked August 16, 2026

What Responsive Design Checker does, with a checked example

Paste a URL and the page loads inside a resizable iframe, letting you watch its layout reflow as the frame moves between mobile, tablet, and desktop widths. Breakpoint presets snap to common phone and tablet sizes; dragging the frame's edge resizes continuously, and the page's own CSS media queries do the reflow work - no screenshots are taken. The URL loads directly in your browser, so nothing you paste is uploaded. The usual surprise: an iframe can change only the width. The embedded page still sees a desktop browser, so user-agent-sniffing sites keep their desktop layout even at 320 px, and many sites deliberately refuse to render inside any iframe.

Worked example

A concrete input and expected output from the current implementation.

Input

https://example.com/ with the 375 px mobile preset

Expected output

The page opens in an iframe exactly 375 px wide, laid out at that width by its own CSS. Dragging the frame's edge to 768 px reflows it instantly - each breakpoint in the page's media queries fires as the frame crosses it - and returning to 375 px restores the narrow layout, with no reload at any point.

The iframe's width is the viewport the page sees, so the result follows mechanically: set the width, and the page's media queries re-evaluate against it. The preview shows only what the page's own CSS does at that width; it does not simulate a phone's user agent, touch input, or pixel density.

How the result is produced

1

Breakpoints and live resize

The tool loads the URL into an iframe whose width is the viewport width the page sees. Presets cover mobile, tablet, and desktop sizes; picking one snaps the frame to that size, and dragging its edge changes the size continuously. Because CSS media queries resolve against the frame's width, each layout change fires the moment the frame crosses a breakpoint, with no page reload.

2

What resizing cannot change

An iframe runs in its host page's browser context, so the embedded site sees the same user agent, touch capability, and device pixel ratio as the tab hosting the tool. Only the frame's dimensions change. A site that serves a separate mobile variant based on user-agent sniffing therefore keeps serving its desktop markup, and the viewport meta tag that mobile browsers honor is ignored inside iframes.

Good uses

  • Verify a CSS change across breakpoints before deploying - find the exact width where navigation wraps badly, text overflows, or a horizontal scrollbar appears.
  • Audit a site you do not control to see whether it genuinely adapts at tablet widths or only jumps between phone and desktop layouts.
  • Reproduce a reported layout bug by setting the frame to the reporter's screen width, such as 375 px, and dragging around it until the broken state appears.

Limits and checks

  • Embedding refusals. Pages that send the X-Frame-Options header or a Content-Security-Policy frame-ancestors directive render as a blank pane or an error. No iframe-based tool can override that; it is the site's policy, not a defect you can fix here.
  • Narrow is not mobile. The frame changes width only. The page still sees a desktop user agent with mouse input, and the viewport meta tag is ignored in iframes, so device-based media queries and UA-sniffed mobile variants never trigger.
  • Live site, live variance. You preview the running site, so results change when the site changes, and your logged-in state usually does not carry over: with third-party cookies blocked, the page loads as a logged-out visitor.

Common questions

Why does my page show a blank pane or refuse to load?

The site is blocking iframe embedding, usually through the X-Frame-Options header or a Content-Security-Policy frame-ancestors directive. The tool cannot override that - no browser-side tool can. Open the URL in its own tab to view it directly, and treat the refusal as information about the site's own embedding policy.

If it looks right at 375 px here, will it look right on a phone?

Not guaranteed. The preview proves the page's CSS reflows correctly at that width, but it does not reproduce a phone: user agent, touch input, pixel density, and viewport-meta handling all differ. A site that sniffs user agents may serve an entirely different page to real phones. Confirm with a device emulator or a physical device.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools