Dragging the corner of a browser window tells you the layout survives being dragged. It does not tell you what happens at 767 pixels, which is the width where half of all responsive bugs live, because you went past it in one motion at about forty pixels a frame.
This loads a page in several frames at once, at fixed widths: the device sizes people actually use, or the pixel either side of each breakpoint, which is where a layout changes and therefore where it breaks. The frames are loaded by your own browser with your own session, so a page behind a login works here and nothing is sent anywhere.
How to use
- Put in an address. Your own site, a staging URL, or a local development server.
- Choose devices, breakpoints, or both. Breakpoints is the one that finds bugs.
- Set the frame height and load.
Each frame is laid out at the device’s CSS width and then scaled down to fit on screen, so the page inside sees the width it would see on the device rather than the width of the box it is shown in.
Example
The breakpoint mode loads ten frames, in pairs:
Just below sm 639 × 900 at 78%
At sm 640 × 900 at 78%
Just below md 767 × 900 at 65%
At md 768 × 900 at 65%
Just below lg 1023 × 900 at 49%
At lg 1024 × 900 at 49%Put those two side by side and a layout that changes from a stack to a grid shows you both halves of the change at once. That is the comparison a dragged window cannot give you, because you can only be at one width at a time.
Pitfalls
A blank frame is usually the site refusing, not a bug here. Most large sites send X-Frame-Options: DENY or a Content-Security-Policy: frame-ancestors rule, and a browser obeys those before any
JavaScript runs. Google, Facebook, most banks and a good number of CMS-hosted marketing sites will never
load in a frame. Your own site, a staging site and localhost will, unless your own headers say otherwise,
which is itself worth knowing.
A frame is not a phone. It gets you the width, and the width is most of the layout. It does not get
you touch input, the device’s fonts, the address bar that appears and disappears as you scroll, Safari’s
particular handling of 100vh, or a slow CPU. Nothing that runs in a desktop browser can give you those.
Device presets are CSS pixels, not hardware pixels. An iPhone 15 has 1179 physical pixels across and reports 393, because the ratio is 3. Media queries compare against the CSS number, which is why a “1179px wide” phone runs your mobile layout. The presets here state both.
Your breakpoints are the ones in your stylesheet. The list here is the common set (640, 768, 1024,
1280, 1536), and if your CSS uses different ones, those are the widths to test. Grep the stylesheet for
@media before trusting any preset list, including this one.
user-agent is unchanged. Server-side device detection sees a desktop browser, so a site that serves
different markup by user agent will serve the desktop markup into a 390-pixel frame. That is a reason to
distrust server-side device detection more than it is a limitation of this.
Scaled frames change what you can read, not what the page does. A frame at 49 percent shows a real 1024px layout at half size: the line lengths and wrapping are correct and the text on screen is too small to judge typography. Turn the scaling off and scroll the rail when that matters.
Third-party cookie rules apply. Inside a frame, the page is a third party. Anything depending on cookies set in a different context can behave differently from the same page in a tab, and a login can fail in the frame while working normally.
Compatibility
Everything happens in your browser. No address is sent to any server here, nothing is stored, and the frames are ordinary iframes fetching whatever you point them at, with your own cookies.
Frames carry sandbox="allow-scripts allow-same-origin allow-forms" and referrerpolicy="no-referrer".
The sandbox stops a framed page navigating this one or opening popups while leaving its own JavaScript
working, which is the part you are trying to look at. The referrer policy means the site you load is not
told which page framed it.
The scaling never enlarges. A 320-pixel frame blown up to 600 would be a lie about how much fits on a small screen, so small frames are shown at their own size and only large ones shrink.
Breakpoint mode uses the pair of widths either side of each breakpoint, one pixel apart. That pair is the
whole point: max-width: 767px and min-width: 768px are two different layouts, and the bug is almost
always in the one you did not look at.
Frequently asked questions
Why will a particular site not load?
Can I test a page behind a login?
Is this the same as the device toolbar in developer tools?
What heights should I use?
vh units will look very different at 600 than
at 900. The default of 720 is a common laptop viewport height.