Chrome can take a screenshot of an entire web page — top to bottom, not just what fits on the screen — without installing anything. The feature is hidden in DevTools and it works on most pages, but not all: some come out with blank images, some only one screen tall. This page shows the steps, explains what the command actually does, and shows the pages where it fails, measured on 2026-11-08, with a fix for each.
The steps
Chrome's DevTools documentation describes the Command Menu route:
- Open the page and open DevTools:
F12, orCtrl+Shift+I(Windows, Linux) /Cmd+Option+I(Mac). - Open the Command Menu: "Press Control + Shift + P (Windows / Linux) or Command + Shift + P (Mac)".
- Type screenshot.
- Choose Capture full size screenshot.
Chrome saves the PNG as a download; in the current DevTools source it also tries to copy the image to the clipboard. The same menu has Capture screenshot (just the visible area), Capture area screenshot (drag a rectangle; "won't work if DevTools is undocked") and Capture node screenshot (the element selected in the Elements panel).
The second route is through device mode: click the device icon in DevTools to emulate a phone or a screen size, then open the More options menu (⋮) above the page. The device mode docs: "To capture a screenshot of the whole page including the content that isn't visible in the viewport, select Capture a full size screenshot from the same menu." This is how you get a full-page screenshot of the mobile layout — at the phone's width and pixel density — and with Show device frame turned on, the phone frame around it.
What the command actually does
DevTools is open source, so we can read what it sends to the page. Its captureFullSizeScreenshot calls the Chrome DevTools Protocol's Page.captureScreenshot with captureBeyondViewport: true (DevTools source): Chrome paints the whole document height in one pass, without scrolling the page. That one fact explains every failure below — anything that only appears when you scroll never appears in the capture.
What we tested, and where it failed
We sent exactly that command, from Puppeteer 25.7 with Chrome 152, to four test pages at a 1280×800 window, and compared it with Puppeteer's own fullPage screenshot:
| Test page | Full-size capture | What went wrong |
|---|---|---|
| Ten sections with lazy-loaded images | 1280×6010, the full height | Only 4 of 10 images had loaded; capturing loaded none more |
A fixed header (position: fixed) |
1280×3200, full height | Fine here: the header appears once, at the top |
Content scrolling inside a <main> element |
1280×800 | Only one screen: the document itself is one screen tall |
A 100vh hero section |
1280×2800 | Fine: the hero stayed 800 px, the window height |
Puppeteer's fullPage gave identical results on all four, so the same advice applies to both.
Lazy images come out blank
Images with loading="lazy" are fetched only when they come close to the visible area. The capture does not scroll, so images further down stay empty boxes. Fix: scroll slowly to the bottom and back before capturing, or paste this in the DevTools Console first:
document.querySelectorAll('img[loading="lazy"]').forEach((img) => (img.loading = 'eager'));
In our test this made the browser request and load all 10 of 10 images within a second; then capture. Pages that load images with their own JavaScript (an intersection observer) still need the scroll.
Pages that scroll inside an element
Many web apps and some site builders lock html and body to the window height and scroll a container instead. Chrome measures the document — one screen — and captures exactly that: our test page came out 800 px tall instead of 4,000. Fix: make the document tall for a moment. In the Console, for our test page:
const s = document.createElement('style');
s.textContent = 'html, body, main { height: auto !important; overflow: visible !important; }';
document.head.append(s);
Then capture: ours was the full 1280×4000. Replace main with the page's scrolling element (in the Elements panel, it is the one with a scroll bar). Reload the page to undo.
Fixed headers, banners and chat widgets
A fixed header appeared once at the top in our test — but on real pages, fixed elements that react to scrolling (shrinking headers, "back to top" buttons, cookie banners, chat bubbles) are captured in whatever state they are in when you click. Scroll back to the very top, close banners and chat windows, and wait a second before capturing.
Other limits
- Very tall pages make very large files. DevTools always saves PNG; in our tests Puppeteer's full-page capture, which sends the same command, still produced a correct PNG at 100,000 px, but a file that size is hard to open. For long articles, Ctrl+P → Save as PDF paginates instead.
- Animations are captured mid-motion; wait until they finish.
- One page at a time. DevTools is a manual tool: every capture is several clicks.
Faster, or many pages: our free tool and the API
Our free full-page screenshot tool runs Chrome on our servers for any public URL: it scrolls through the page first so lazy images load, removes cookie banners and ads, and returns the image — no DevTools, no snippets. It does not unroll pages that scroll inside an element either; for those, use the console fix above in your own browser.
For many pages or on a schedule, the screenshot API takes the same options — full_page, lazy_load, block_cookie_banners, a device preset for mobile layouts — in one request per URL. A full-page screenshot uses 2 renders of the monthly quota, up to 16,000 pixels tall. If you script screenshots with Puppeteer instead, our Puppeteer full-page guide measured its limits in detail.
