Responsive Breakpoint Previewer

Many websites set the X-Frame-Options or Content-Security-Policy HTTP headers to prevent their pages from being loaded inside iframes. This is a security measure to prevent clickjacking attacks. When a site blocks iframe embedding, the preview will show a blank page or an error. Solution: use the HTML mode — copy the page source or paste your own HTML to preview it without iframe restrictions.

Yes. All device presets use the CSS viewport dimensions (device-independent pixels) reported by each device's browser. For example, iPhone 14 is 390×844 CSS pixels (not the physical resolution of 1170×2532 hardware pixels). These are the dimensions that CSS media queries and responsive breakpoints respond to.

Tailwind uses a mobile-first breakpoint system with min-width media queries: sm (≥640px), md (≥768px), lg (≥1024px), xl (≥1280px), 2xl (≥1536px). Styles without a breakpoint prefix apply at all sizes. This tool highlights which breakpoints are active at the current preview width, making it easy to understand which responsive classes will apply.

Yes. In HTML mode, you can paste complete HTML including <link> tags to external stylesheets, inline <style> blocks, and <script> tags. The HTML is rendered in a sandboxed iframe, so your CSS framework (Tailwind, Bootstrap, etc.) will load and apply normally. Include the CDN link in your HTML to test with any framework.

The Rotate button swaps the width and height values. For example, iPhone 14 in portrait is 390×844, and in landscape it becomes 844×390. This is the same behavior as rotating a physical device. CSS media queries respond to the new width, so breakpoints may change when you rotate — exactly as they would on a real device.

No — it's a fast, useful approximation, not a substitute. This tool renders your page at a device's CSS viewport dimensions, so it accurately shows which breakpoints and media queries fire and how the layout reflows. But it can't reproduce everything a real device does: actual touch interactions and tap-target sizing, real rendering-engine quirks (iOS Safari behaves differently from desktop Chrome even at the same width), performance on slower hardware, the dynamic mobile address bar that changes viewport height, device pixel ratio and image sharpness, system fonts, and platform-specific input behaviors. Use the previewer for rapid layout iteration across many sizes, then confirm critical flows on real hardware (or at least the browser's own device-emulation with touch and throttling) before shipping. Layout is what this tool nails; feel and performance need a real device.

Yes, mobile-first is the recommended approach, and it maps directly to min-width media queries. You write your base styles for the smallest screen (no media query), then ADD complexity at larger widths with min-width breakpoints: the base CSS is mobile, @media (min-width: 768px) layers on tablet adjustments, @media (min-width: 1024px) adds desktop. This is the opposite of desktop-first (max-width queries that strip things away as screens shrink). Mobile-first wins because it forces you to prioritize essential content, produces simpler base CSS, and matches how frameworks like Tailwind work (unprefixed = all sizes, sm:/md:/lg: = and up). Choose breakpoints based on where YOUR content breaks, not specific device models — resize until the layout looks awkward, and put a breakpoint there.