Responsive screenshot
View and capture a website across phone, tablet, laptop and large-screen frames at once.
A blank white frame means that website blocks embedding with X-Frame-Options - it is not a fault in this tool, and there is no way around it. Use the new-tab button to view it directly.
Phone 390 × 844 · Tablet 768 × 1024 · Laptop 1280 × 800 · Desktop 1920 × 1080
Frequently asked questions
Because that site refuses to be embedded in another page. Its server sends an
X-Frame-Options header or Content-Security-Policy: frame-ancestors, and
the browser honours that by leaving the frame empty. This is anti-clickjacking protection: it stops
an attacker embedding a real login page inside a fake one and tricking you into clicking.
Google, Facebook, GitHub and plenty of large news sites all block it. There is no way around it from the browser side, and every responsive-preview tool of this kind hits exactly the same wall. To preview a blocked site you need a screenshot service running a real browser on a server.
The live site. Your website is embedded in four differently sized frames, so you can scroll, click and fill in forms right inside them - these are not static images. To keep a copy, use the “Download image” button; see the question about screen sharing below.
It matches on the part that matters most - the viewport. The page inside each frame gets exactly that width, so it picks the same CSS breakpoints as it would on the real thing.
But it differs in a few ways: the browser drawing the page is still the browser on your machine, so the fonts, engine and version are yours rather than Safari on iOS or Chrome on Android. There is no real touch input, so tap, swipe and hover behave differently. And the user agent is still your machine - see the next question.
Most likely that site picks its layout from the user agent rather than the screen width. The browser inside the frame still reports your computer's user agent, so the server returns the desktop version no matter how wide the frame is. If that is what is happening, the fix is to switch to responsive media queries - or test with device emulation in DevTools, which can change the user agent too.
This page runs over https, and browsers forbid an https page from embedding http content - this is called mixed content. The tool tells you when it runs into that. The fix is to use the site's https version, or to open it directly in a new tab with the button alongside.
Yes, as long as your own machine can reach that address, because the frames
load straight from your browser and never go through any server of mine. The one obstacle is the
mixed-content rule above: http://localhost:3000 will be blocked. The way round it is
to run your dev server over https, or open this tool from your own localhost copy of the site.
Not to any nguyenlap.net server. Everything happens in your browser; the URL is only written into the address bar so you can copy and share it.
To be clear about one thing though: the website you enter does receive a real visit from your browser - with your IP address, that site's own cookies if you are signed in, and the fact that the visit came from nguyenlap.net. That is unavoidable when embedding a live page.
Because it is the only route left. The content in the four frames belongs to another website, and browsers absolutely forbid one page from reading another page's pixels - which is why libraries like html2canvas would only ever draw four white boxes. The alternative is to ask the browser itself to take the shot, and that requires your explicit consent.
In the dialog that appears, choose this tab (This tab / Chrome Tab). Picking the whole screen or a window means the tool has no way to know where the page sits inside the capture to crop it correctly, and it will tell you so. The image is cropped to the grey stage holding the four devices, saved as PNG, and sent nowhere. This works well in Chrome and Edge; Firefox and Safari do not allow picking a single tab, so taking your own screenshot is quicker.
Scrollbars are browser chrome rather than page content, and showing them makes the device cluster look a mess. The page inside the frame is cross-origin so no CSS can be injected to hide them; the only option is to crop that strip away. The frame keeps the full device size so breakpoints are unaffected - the visible area is just narrower and shorter by one scrollbar width. You can still scroll normally with a mouse or a finger.
One side effect is worth knowing: if your page produces a horizontal
scrollbar at some width, you will no longer see it here. The usual culprit is
width: 100vw - that unit includes the vertical scrollbar width, so the element ends up
about 15px wider than the content area and pushes the page sideways. If you suspect it, open the
page in a new tab and narrow the window to check.
They are common viewports in CSS pixels: 390 × 844 for a recent iPhone, 768 × 1024 for an iPad in portrait, 1280 × 800 for a 13-14 inch laptop, and 1920 × 1080 for a typical external monitor. These are the CSS figures the page sees, not physical resolution - an iPhone at 390 CSS points actually has 1170 real pixels. Select a single device and you also get a button to rotate it to landscape.
This tool runs entirely in your browser. Nothing you type is sent anywhere.