b2KIT

Responsive Preview Tool

Paste HTML or enter a URL to preview at iPhone, iPad, and desktop viewport sizes side-by-side with real iframe rendering.

How to Use Responsive Preview Tool

  1. 1

    Enter a URL

    Type the website URL you want to preview responsively.

  2. 2

    Choose device sizes

    Select phone, tablet, laptop, or desktop viewport widths.

  3. 3

    Compare layouts

    View your site at different screen sizes side by side.

Tested tool guide Tested browser tools Checked August 16, 2026

What Responsive Preview Tool does, with a checked example

This tool renders the same page in three real iframes at iPhone, iPad, and desktop viewport sizes, arranged side by side so you can judge a layout at three widths at once. Paste self-contained HTML into the field to preview your own markup, or enter a URL to load a live page into all three panes. The surprise most people hit first: popular sites often come back as blank panes because they forbid being embedded in a frame - the page is fine in a normal tab, but the target site's security headers refuse the iframe.

Worked example

A concrete input and expected output from the current implementation.

Input

<!DOCTYPE html>
<html>
<head>
<style>
  body { font-family: sans-serif; padding: 16px; }
  @media (max-width: 600px) { body { background: #fff3cd; } }
</style>
</head>
<body>
  <h1>Sale ends Friday</h1>
  <p>Free delivery on orders over $50, while stock lasts.</p>
</body>
</html>

Expected output

Three panes side by side, labeled iPhone, iPad, and desktop, each showing the heading and the paragraph. The iPhone pane has a pale yellow background; the iPad and desktop panes keep the default background. The paragraph reflows into a narrower column in the phone pane.

The style rule fires only below 600px. The phone viewport measures well under 600px, while the iPad and desktop viewports measure well above it, so the background change appears in exactly one pane - a live demonstration that each pane evaluates media queries against its own width.

How the result is produced

1

Two input modes

The field takes either self-contained HTML or a URL. Pasted markup is rendered as-is in each of the three panes; a URL is loaded by each pane as a live page. Both modes produce the same iPhone, iPad, and desktop layout, but the inputs behave differently: pasted markup travels with the preview and must carry its own assets, while a URL brings the real page with its scripts and styles.

2

How the panes measure

Each pane is an iframe, and an iframe has its own viewport: the tool fixes each pane's width while the host page keeps your size, so layout media queries evaluate per pane. What an iframe does not change is the browser identity or input capabilities - the page still sees your desktop browser, so sites that branch on user agent, hover, or pointer can show desktop behavior in the phone pane.

Good uses

  • Confirm a breakpoint flip before publishing: paste the page or component HTML and verify the navigation collapses to a menu, grid items stack, and nothing overflows at phone width.
  • Judge a site you do not control - a client's current homepage, a CMS template, a competitor's page - at phone and tablet widths from one screen instead of opening it and resizing repeatedly.
  • Iterate on a self-contained snippet such as a signup form, pricing card, or article header, seeing all three widths update at once as you edit the markup.

Limits and checks

  • A blank or empty URL pane usually means the target site forbids framing via X-Frame-Options or a Content-Security-Policy frame-ancestors directive. The site works in a normal tab; the refusal comes from the target server, and no preview tool can override it.
  • Pasted HTML has no project base URL, so relative paths to images, stylesheets, and fonts resolve against the tool's own page and fail. Inline assets or use absolute URLs; otherwise the phone pane can look broken for reasons unrelated to your layout.
  • The preview simulates width only. The rendering browser is still your desktop browser: touch gestures do not exist, and pages that sniff the user agent or use hover and pointer media features get the desktop variant. Treat the result as a layout check, not a device test.

Common questions

Why does the phone pane not match what I see on my actual phone?

Because the pane is your desktop browser in a phone-sized viewport, not a phone. Pane width drives layout media queries, but the user agent, input capabilities, and font rendering are still your desktop's, and touch gestures are absent. Use the tool for layout and reflow; verify gestures, performance, and rendering on real hardware.

Can I preview a page that requires a login?

Usually not usefully. An authenticated page needs your session cookies, and the preview runs in its own browsing context with no access to the tabs where you are signed in; most browsers also block the third-party cookies such an embedded page would receive. Expect the logged-out view or a login screen, and test authenticated flows on the real site.

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