Inside Screenshot PDF: How a Long Webpage Becomes One Continuous Capture

A full-page screenshot is not a photograph of an entire document taken in one instant. A browser normally exposes only the pixels inside the current viewport. Capturing a long page therefore requires a controlled sequence: identify what scrolls, measure it, move through it, capture visible slices, and assemble those slices without silently changing the source page.

This article documents the current Screenshot PDF extension pipeline in version 0.0.13. It is based on the shipped capture and editor code, not on an idealized diagram. The boundaries below matter because a reproducible limitation is more useful than a promise that every page can be captured perfectly.

1. The extension starts with the active tab

Screenshot PDF uses a Manifest V3 Chrome extension and the active browser tab. Chrome internal pages such as chrome://settings and the Chrome Web Store are restricted by the browser and are rejected before capture begins. Ordinary public pages, authenticated pages visible to the user, and many application screens can be captured because the extension works inside the user's current session.

That access does not mean every embedded surface is available. Cross-origin frames, protected video, WebGL, virtualized lists, and content drawn outside the normal page flow can still require a different export method. Chrome documents the underlying visible-tab operation in its tabs.captureVisibleTab API.

2. Finding the real scroll container

Not every site scrolls the document body. Dashboards frequently place the scrollable area inside a div, while the outer page remains fixed. The extension first checks the usual document scrolling elements. If none qualifies, it examines common content containers and selects a visible element with vertical overflow and the largest useful area.

This choice is consequential. Measuring the wrong element produces an image that stops after one screen even though the user can see more content. A practical diagnostic is to compare the scrollbar the user moves with the element whose scrollHeight changes in DevTools. The extension makes this choice automatically, but nested or horizontally scrolling applications may still need a sectional capture.

3. Measuring before moving

The capture payload records page width, page height, viewport width, viewport height, and device pixel ratio. CSS pixels describe the page layout; captured PNG pixels may be denser on a high-DPI display. The editor later derives the intrinsic pixel ratio from the first captured slice so that CSS coordinates and image coordinates remain aligned.

The current full-page workflow places an explicit upper boundary at 15,000 CSS pixels of height per run. The boundary prevents an unbounded feed from consuming memory indefinitely. If a page is longer, capture named sections with visible overlap, or use an official export from the source service. Do not describe a result beyond that boundary as complete.

4. Capturing one viewport at a time

The extension moves through the page in viewport-height steps. After each requested scroll, it reads the actual scroll position rather than assuming the page moved exactly as requested. This protects the final slice, where the browser may clamp the scroll position at the bottom.

The content script waits for two animation frames and then approximately 300 milliseconds after moving. The background workflow adds another short pause between slices. These waits give ordinary layouts time to settle, but they are not a guarantee that every lazy image, animation, or network request has completed. For media-heavy pages, scroll through the page once manually and wait for placeholders to resolve before starting the capture.

Chrome can temporarily throttle visible-tab capture. When the error matches Chrome's capture-rate limit, Screenshot PDF retries up to three times with a one-second delay. Other errors are reported instead of being hidden. This distinction avoids turning a persistent permission or rendering problem into a long silent loop.

5. Handling floating interface elements

Sticky headers, cookie controls, chat launchers, and floating toolbars are attached to the viewport rather than a single place in the document. If they remain visible during every slice, they appear repeatedly in the stitched image. Screenshot PDF records floating candidates, keeps them in the first slice, and hides them from later slices by changing visibility rather than rewriting layout position.

Visibility is restored after success and also inside the failure path. The page is returned to the top, the capture progress interface is removed, and the extension badge is cleared. This cleanup is part of correctness: a tool should not leave the source page visually altered when a capture fails.

6. Passing slices to the editor

Each slice carries its actual vertical position. The editor loads all PNG slices, creates a white Canvas, and draws them at positions derived from CSS coordinates, intrinsic device pixel ratio, and any memory-driven scale factor. The useful height ends at the last captured viewport rather than automatically trusting an earlier page measurement that may have changed.

This stitching method works well for stable, vertically scrolling layouts. It cannot reconstruct content that never existed in a single scroll state. Virtualized tables may unload earlier rows as new rows appear; live dashboards may change values between slices; auto-rotating components may show different frames. In those cases, use smaller sections or a source-native export.

7. A reproducible capture record

For an ordinary personal document, a visual review may be enough. For support evidence, research, design review, or records work, record:

• public URL or a non-sensitive description of the authenticated page;
• Chrome and extension versions;
• viewport size, zoom, and device pixel ratio;
• intended start and endpoint;
• whether content was expanded or pre-scrolled;
• whether the page exceeded 15,000 CSS pixels;
• any missing frame, embedded surface, or live value.

Screenshot PDF includes a public reproducible capture fixture with a sticky header, fixed control, lazy content, a table, alternating backgrounds, and a final endpoint. Use it to distinguish a general capture problem from a site-specific layout problem.

What the pipeline does not prove

A visually complete screenshot does not prove authenticity, legal admissibility, or an unmodified source. It records rendered pixels from a browser session. Keep the source URL, access time, and relevant context separately. When the source service offers a signed statement, structured export, invoice, or born-digital PDF, preserve that stronger source alongside the screenshot.

The current pipeline is deliberately bounded: measure, capture at actual positions, retry only known throttling, restore the page, assemble locally, and ask the user to inspect the output. Those boundaries are what make a long-page capture understandable and repeatable.