Responsive viewport preview
Render a page, or a block of HTML you paste in, inside a frame set to a chosen viewport size — and when a site refuses to be framed, open it in a real browser window at that exact size instead, which works for every site. Two honest caveats before you start: most real websites do refuse framing, and either way this is a resized window in your own browser rather than a device.
Add this when pasted HTML uses relative links such as /logo.png or assets/site.css.
If the frame is blank, the site refused to be framed. Sites send an X-Frame-Options header or a frame-ancestors content security policy to stop other pages embedding them, and browsers obey it silently — Google, Facebook, GitHub, most banks and a growing share of ordinary sites all do this. No web page can override it, and none should be able to. Use “Open at this size” for those: it opens the address in a real browser window at the chosen viewport, which works for every site because nothing is embedded. Your browser's own device emulation panel and the HTML mode above are the other two ways round it.
QuietUtils itself does not upload or store the pasted HTML or URL. HTML is rendered in a sandboxed frame with no access to this page, but remote resources and scripts inside pasted HTML can make network requests or send the pasted content elsewhere. URL mode loads the destination in your browser, so the full address is sent to that site and it may load its own third-party resources. URL mode and pasted HTML with scripts or event handlers ask for confirmation before loading or running them.
What a frame can and cannot tell you
The frame here is a real browser viewport at the width and height you choose, so anything that depends on viewport size behaves correctly inside it. Media queries fire at the right breakpoints. Percentage and viewport units resolve against the frame. Flex and grid tracks wrap where they would wrap. Container queries respond. Text reflows, images resize, and a navigation bar collapses into its menu button exactly as it would at that width on a phone. For finding the width at which a layout falls apart, that is the whole job, and it is genuinely useful.
What the frame is not is a device. It is your own browser, your own rendering engine, your own fonts, running on your own machine at whatever pixel density your screen happens to have. A 375 by 667 frame in Chrome on a desktop is not an iPhone SE: it is Chrome pretending to be narrow. Touch input does not exist, so hover styles apply where a phone would never show them and tap targets feel fine when they are too small. The device pixel ratio is your monitor's, so a retina screenshot is not what you are looking at. Mobile Safari's particular behaviours — its dynamic address bar changing the viewport height, its handling of one hundred viewport-height units, its font inflation, its scroll and momentum behaviour — are absent because Safari is not what is drawing this. Neither is the phone's GPU, so a smooth animation here says nothing about a smooth animation there.
Treat this as a layout and breakpoint check, which it does well, and treat a real device or a proper device lab as the thing that tells you how a page actually feels. The browser's own device emulation panel sits usefully in between: it fakes the pixel ratio, the user agent string and touch events, which this page does not.
Why most URLs will not load, and what to do instead
Loading another site in a frame is a decision that site gets to make, not you. Two mechanisms enforce it. The older is the X-Frame-Options response header, with values DENY and SAMEORIGIN. The current one is the frame-ancestors directive of a content security policy, which lists exactly which origins may embed the page. Both exist for a good reason: without them an attacker could load your bank in an invisible frame over a decoy page and collect your clicks, a trick called clickjacking. Any site with a login form has a strong incentive to switch framing off, and most large sites have.
When that happens the browser blocks the load and usually reports it only in the console. The frame stays blank, and — depending on the browser — the load event may fire anyway, so a page cannot reliably tell the difference between "refused" and "loaded something empty". A URL can also break because this safety sandbox gives it an opaque origin: origin-bound storage, same-origin requests and module scripts may not work as they do in a normal tab. That is why the explanation above appears whenever a URL is loaded rather than only when a failure is detected. The frame cannot read this page, but the tradeoff is that some applications cannot be previewed faithfully here.
The practical alternatives are straightforward. For a site you control, add your own origin to frame-ancestors in a development build. For a site you do not control, use the device emulation in your browser's developer tools, which resizes the real viewport rather than embedding anything. For a component, an email template or a snippet of markup, paste it into the HTML mode on this page. The sandbox means the markup cannot touch this page, but any remote resources or scripts in the pasted markup can still make their own network requests.
Questions people ask
Why does my site show a blank frame?
It may send a header telling browsers not to allow framing, or it may depend on origin-bound storage, same-origin requests or module scripts that this opaque-origin sandbox cannot provide. Open the console and network panel to tell which one happened. No web page can override a site's frame policy while keeping this isolation. Use the Open at this size button instead: it opens the address in a real browser window sized to the viewport, so the site gets its normal origin and every site can load.
Is this the same as Chrome's device toolbar?
No, and the difference matters. The device toolbar in developer tools resizes the actual page viewport and additionally simulates a device pixel ratio, sends a mobile user agent string, and dispatches touch events instead of mouse events, so media queries for hover and pointer type respond correctly. This page only sets the size of a frame. That covers breakpoints and layout, which is most of what people check, but it does not fake touch, pixel density or the user agent. Where those matter, use the browser's own panel.
Is it safe to paste HTML in here?
The markup is rendered in an iframe with a sandbox attribute that allows scripts but deliberately does not allow same-origin access. That combination gives the frame an opaque origin, so script inside it cannot read this page, its storage or its cookies, and cannot navigate the top-level window. QuietUtils itself does not transmit the markup. However, remote resources and scripts inside what you paste can make network requests, read the whole preview document, and send that content elsewhere. Remove scripts and remote links before pasting confidential markup.
What do the percentages under each frame mean?
A 1280-pixel-wide frame does not fit in a 700-pixel column, so the frame is rendered at its true size and then scaled down visually with a CSS transform. The caption states both numbers: the real viewport size the page inside the frame sees, and the percentage it is being displayed at. The page inside is genuinely 1280 pixels wide and its media queries behave accordingly — only your view of it is shrunk. Frames are never scaled above 100 per cent, because an enlarged preview would misrepresent text size and spacing.
Which sizes should I actually test?
Widths matter far more than heights, and the useful ones cluster into a few bands: around 360 to 400 for most phones in portrait, around 744 to 834 for tablets in portrait, around 1024 to 1180 for tablets in landscape and small laptops, and 1280 and above for desktops. The presets here cover each band. More valuable than any specific device, though, is dragging the custom width slowly across a range and watching where the layout breaks — real breakages tend to happen at awkward in-between widths that no device in a preset list happens to use.
Can I preview a page that needs a login?
Not usefully. A site that requires authentication is precisely the sort that blocks framing, and even where it does not, the frame would need the session cookie, which modern cookie policies increasingly withhold from third-party contexts. For anything behind a login, resize your own browser window or use the device emulation panel in developer tools, both of which operate inside the session you are already in.