A full-page capture is a reconstruction, not a photograph

Press the capture button on a long article and you expect a photograph of the page (one click, every pixel below the fold included). That expectation is the myth this tutorial dismantles. A full page screenshot is never a single exposure of a tall page, because no screen is that tall. It is a reconstruction, assembled one of two ways: several viewport-sized tiles shot while scrolling and glued together, or one render at the page's full scroll height, "as if you had a very tall screen and the page could fit it entirely," in Playwright's own definition. Each reconstruction fails differently, and the failure tells you which method built the image.

This tutorial answers the question our screenshot tool hears most: how do I capture the whole page instead of just the viewport? You get three methods in a comparison table, nine breakages described precisely enough to recognize on sight, and a short decision rule. The where-does-my-capture-go question belongs to the custody companion post: one line per method here, nothing more.

How a full-page capture works in four steps

Every tool below runs the same four-step pipeline. The methods differ only at step two.

1. Measure the page. The capturer reads the document's full scroll height and width, which almost always exceed the viewport. That number decides everything downstream: tile count for a stitcher, viewport height for a one-shot render.
2. Collect every row of pixels. Either shoot one viewport tile per scroll stop, or stretch the rendering viewport to the full document height and shoot once. Stitching sees the page the way you do; a tall render sees it the way a very tall screen would.
3. Assemble the image. A stitcher aligns tile edges into one tall bitmap. A single-shot render skips this step: nothing to join, hence no seams, hence the smear failures the gallery shows.
4. Save at the right density and format. The bitmap is written at the display's device-pixel ratio as PNG or JPEG. Density and format decide whether the file is crisp, huge, or both; the retina section keeps this to one paragraph each.

The three ways to capture a whole page

UNVERIFIED: a keyboard Command-Menu variant of the Chrome path is said to live on a linked "4 ways" page I did not read, so no path for it is given here. UNVERIFIED: the consumer support page for Firefox screenshots would not load, so every Firefox path above comes from the developer source docs, read verbatim.

Method 1: viewport stitching: scroll, shoot, stitch

Stitching is the method inside most one-click extensions. It scrolls your real tab top to bottom, shoots each viewport, and joins the strips. Because it drives your tab, it inherits your session: dashboards, logged-in views, and metered articles render as you see them. Where do captures go? An extension stitcher runs beside your tabs under browser permissions: the full custody breakdown is in our companion post on online screenshot tools without downloads.

What breaks it is anything that changes between scroll stops. A sticky header re-renders in every tile, so it appears once per tile. An image with loading="lazy" ("Defers loading the image until it reaches a calculated distance from the viewport, as defined by the browser," per MDN's img reference) never loads if its tile is captured before it intersects the viewport. Carousels advance and parallax backgrounds re-offset at each stop, drawing a seam where two tiles meet. Pages with no defined bottom never finish: decide the stop rule (which fold counts as "the page") before you start.

Method 2: headless full-height render: one shot at document height

This method never scrolls. It sizes the rendering viewport to the document's full scroll height and exposes a single frame, which is why Puppeteer keeps fullPage off by default alongside options like captureBeyondViewport ("Capture the screenshot beyond the viewport"): the tall render is a deliberate choice, standardized as screen-capture commands in the W3C WebDriver specification. Our own online screenshot tool offers full-page as a labeled "Full page" switch, on by default (the choice is remembered in localStorage and sent as fullPage in the capture request), which makes it the worked headless-render example for this post. Where do captures go? A server render loads your URL on infrastructure that is not yours: one line is all this gets; the full custody breakdown lives in the companion post.

What breaks it is the flip side of never scrolling. The renderer holds none of your cookies, so session pages come back logged out. Layouts draw at the automation width, not your window width, so a "desktop" capture can carry a mobile hamburger. Viewport-anchored chrome suffers most: a fixed element is "positioned relative to its initial containing block, which is the viewport in the case of visual media," per MDN's position reference: inside a 10,000-pixel-tall viewport that anchor stretches into a streak. Canvas regions can come back blank when the frame freezes before paint, and very long pages can fail or time out on render services (hedged: no vendor timing source was read).

Method 3: browser-native capture: the honest baseline

Native capture is the control group: no extension, no server, no install. Chrome's Device-Mode menu gives both granularities from one place: viewport shot or full-size shot of everything below the fold. Firefox splits the job three ways: the toolbox button for whole pages, "Screenshot Node" for single elements, and :screenshot in the console when you need flags like --dpr or --delay. Where do captures go? Nowhere: a native capture never leaves your machine; if custody is your whole question, start with the companion post.

What breaks it is page truth, not machinery. A native full-size shot resembles a headless render of your own session: your cookies and width survive, yet animations, paywalls, and hover states still misbehave. Interactive states persist only when frozen first: the exact job of the --delay flag. Native capture answers "which tool do I trust" perfectly and "which page will cooperate" not at all, which is why the gallery below is organized by visual signature rather than by tool.

Failure gallery: what each breakage looks like

Match the symptom first, then switch to the method that avoids it.

1. Duplicated sticky header. The same nav bar or cookie bar repeats down the image at regular viewport-height intervals. Cause: fixed and sticky positioning re-rendered once per stitch tile. Avoid with: headless full-height or native full-size, where each element lays out once.

1. Blank lazy-load boxes. Gray or empty rectangles holding correct layout space (not broken-image icons) starting below the first viewport. Cause: tiles captured before those images intersected the viewport, so lazy loading never fired. Avoid with: a stitcher that scrolls every tile fully into view, or a full-height render that forces intersection.

2. Animation seam. A carousel, loader, or shimmer caught mid-transition with a hard horizontal discontinuity where two tiles met. Cause: wall-clock time advanced between tiles. Avoid with: single-shot renders only, never stitch a moving page (pausing animations first is an unsourced tip, not a sourced fact).

3. Parallax banding. A background layer offset against the foreground at repeating intervals, like a misregistered print. Cause: scroll-offset backgrounds re-rendered per tile. Avoid with: single-shot render.

4. Smeared fixed element. A header, sidebar, or chat bubble stretched into a full-height vertical streak. Cause: a viewport-anchored element drawn inside a viewport thousands of pixels tall. Avoid with: stitching or a plain viewport clip.

5. Wrong-breakpoint render. A mobile hamburger on a supposedly desktop capture, or a desktop mega-menu on a supposedly mobile one. Cause: the automation width differed from the claimed device. Avoid with: native capture at your real window, or an explicit width you set and check.

6. Logged-out capture. A login wall, paywall, or emptied dashboard where your own session shows content. Cause: the server renderer holds no cookies. Avoid with: stitching or native capture, both of which run inside your session.

7. Cookie banner in the capture. A consent modal frozen mid-page, sometimes repeated across tiles. This is a workflow failure, not a rendering one. Dismiss every banner before capturing; banner copy varies by vendor and is never quoted here.

8. Infinite-scroll non-termination. The capture spins or grows without finishing. Cause: no defined bottom exists. Avoid with: a stop rule chosen up front (which fold counts as "the page"), since no method defines the bottom for you (hedged methodology advice, not a sourced threshold).

Which method for which page: the decision rule

• Logged-in, paywalled, or SSO-gated page → stitching or browser-native. Only your session sees the content; a server render has no cookies.
• Long marketing or documentation page with sticky nav and lazy images → headless full-height or native full-size, with a full scroll-through first so lazy content intersects the viewport; inspect the result for smeared fixed elements after.
• Page with animations or parallax → single-shot (headless or native), never stitch; pause or freeze animation state first where the tool allows (tip, hedged).
• Responsive check where the breakpoint must be true → native at your real window, or verify the automation width explicitly.
• Zero-trust proof where custody is the question → native; the where-does-it-go analysis is one line per method here and lives in full in the custody companion post.
• Infinite scroll → set the stop rule before capturing; no method defines the bottom for you.

Retina pixels and file formats in one paragraph each

Retina density is simple math with a real cost. The device-pixel ratio "returns the ratio of the resolution in physical pixels to the resolution in CSS pixels for the current display device," per MDN: 1 means a classic 96 DPI display, 2 means HiDPI/Retina, and 2x doubles each dimension, quadrupling total pixels and roughly quadrupling file size. When a full-page capture looks soft on a Retina screen, the ratio was 1 where it should have been 2; when the file is enormous, the reverse. The sizing and savings math behind that trade-off belongs to our post on reducing image file size.

Format choice is convention, stated once: PNG for text and interface captures where lossless edges keep small type readable at any zoom, JPEG for photo-heavy pages where file size matters more than pixel-perfect glyphs. Codecs, quality sliders, and measured savings live in the image-size post, which owns depth here by design.

Limits: what a full-page capture cannot do

Paywalls and single sign-on draw a hard line: a server render returns the logged-out page, while your-session methods show the content but hand you redistribution questions this tutorial does not answer beyond that neutral sentence. Interactive states survive only through a delay or freeze (the exact job of Firefox's --delay), and no other path preserves them. Video is a still by definition: the capture freezes one frame, and motion content stays motion. Canvas regions can freeze blank when captured before paint (hedged: no timing figures). Cookie banners must be dismissed before capturing, never after. Very long pages can fail or time out on render services (hedged: no source read, never numbers). And when the deliverable is a multi-page text document rather than pixel proof, consider rendering to a document instead: our HTML-to-image converter covers snippet-sized source renders, and printable documents have their own pipeline.

Related Tools & Further Reading

Try the worked example: our online screenshot tool captures full pages from a URL with the "Full page" switch on by default.

• Online screenshot tools without downloads — the custody companion: which captures render on a server, which stay local, and where each one loses.
• Reduce image file size — retina costs, formats, and measured savings for the captures you just took.
• HTML-to-image converter — for pasted markup snippets rather than live URLs.
• Browser tools vs desktop software — where the install-vs-tab boundary sits for capture workflows.