Responsive Design Tester | Website Blueprints

What this tester actually does

The tool loads your page in an iframe sized to a device's CSS viewport, so the page's media queries, container queries and vw units behave exactly as they would on a screen of that width. The frame is then scaled down visually with a CSS transform so a 1920px desktop layout fits on your monitor. The page inside still thinks it is 1920px wide.

Two honest limits worth knowing:

It is a viewport test, not a device emulator. The user agent, pixel density, touch events, the iOS Safari toolbar and font rendering all come from your own browser. Sites that serve different HTML based on user agent will show you their desktop version at a phone width.
Some sites refuse to be framed. Google, GitHub, banks, social networks and many large sites send X-Frame-Options: DENY or a CSP frame-ancestors rule. Browsers then show a blank or error frame, and no website tool can get around it. That is deliberate clickjacking protection.

The best way to use it

Point it at your own work: a staging URL, a client preview link, or your dev server. Browsers treat http://localhost as a secure origin, so http://localhost:5173 or http://127.0.0.1:8000 load fine even though this page is served over HTTPS. Other plain http:// sites are blocked as mixed content, so use their HTTPS version.

If your own site will not frame, check your server headers. On Apache (including Hostinger) a typical security block looks like this, and you can relax it for a trusted origin:

<IfModule mod_headers.c>
  # Blocks all framing, including this tester
  Header always set X-Frame-Options "SAMEORIGIN"
  # Modern equivalent, allows one extra origin
  Header always set Content-Security-Policy "frame-ancestors 'self' https://websiteblueprints.tech"
</IfModule>

Only loosen this if you understand the trade-off, and keep production locked down. Testing a staging copy is usually the better answer.

A quick responsive QA routine

Start at iPhone SE (375px). It is the narrowest common phone and exposes most overflow problems: long words, fixed widths, wide tables and images without max-width: 100%.
Rotate it. Landscape phones have very little height, which breaks full-screen heroes and sticky headers.
Check 768px and 1024px. Tablets are where two-column layouts squeeze and navigation often switches modes.
Pick Custom and drag the right edge slowly from 320px to 1600px. Layouts tend to break between breakpoints, not on them.
Switch to All devices for a final side-by-side look before you ship, then confirm on one real phone.

For type that scales smoothly across all these widths without a pile of breakpoints, try the fluid type scale generator.

Frequently asked questions

Why is the preview blank for some websites?

Many sites send an X-Frame-Options header or a Content-Security-Policy frame-ancestors rule that tells browsers not to show them inside another page. That protects against clickjacking and cannot be bypassed from a browser tool. Test your own site, a staging copy, or localhost instead.

Does this show exactly what a real iPhone shows?

It shows the same viewport width and height, which is what drives CSS media queries and layout. It does not change the user agent, device pixel ratio, touch behavior or Safari-specific rendering, so do a final check on a real device or in browser DevTools device mode.

Can I test a site running on localhost?

Yes. Browsers treat http://localhost as a trusted origin, so you can enter something like http://localhost:3000 and preview your dev server at every size while you work.

What breakpoints should I test?

At minimum 375px (small phones), around 768px (tablets portrait), 1024px (tablets landscape and small laptops) and 1366px or wider. Then drag the custom frame slowly through the whole range to catch layouts that break between your breakpoints.