# Why a Full-Page Screenshot Misses Your Scrolling Panel on Mac

Canonical: https://www.lazyscreenshots.com/blog/full-page-screenshot-missing-scroll-panel/
Author: Ali Abouelatta (https://www.lazyscreenshots.com/authors/ali-abouelatta/)
Published: 2026-09-19
Updated: 2026-09-19
Research type: Sourced diagnostic guide
Method: Primary documentation plus two selected public developer reports, dated 2021 and 2026. The numbered-content diagnostic is an original proposed protocol, not an executed benchmark; the example arithmetic is hypothetical. Sources checked September 19, 2026.

A full-page screenshot can include the footer and still miss most of a table.

If the table scrolls inside its own panel, capturing the surrounding page does not establish that you captured every row. Before trying another screenshot app, identify which part of the interface actually moves. A dashboard can contain several independent scroll areas, each showing a different slice of its content.

This confusion appears in two specific public reports. On April 15, 2021, a developer asked why [html2canvas captured only the visible part of a scrolling div](https://stackoverflow.com/questions/67103097/html2canvas-render-only-the-visible-part-of-div-element). On January 7, 2026, another reported the same expectation gap with [Playwright 1.57.0 element screenshots](https://github.com/microsoft/playwright/issues/38699). The latter issue was marked closed as not planned when checked on September 19, 2026.

Both reports distinguish selecting a container from capturing everything inside it.

## Find the thing that scrolls

Chrome documents separate [full-page, area, and node screenshot methods](https://developer.chrome.com/blog/devtools-tips-33), including nodes larger than the screen. Those options describe different capture targets. A node with tall content and a short panel that clips its contents require different checks.

Playwright makes its own behavior explicit: an [element screenshot](https://playwright.dev/docs/api/class-locator#locator-screenshot) is clipped to the element’s size and position. For a scrollable container, only its currently scrolled content appears. That is Playwright’s contract; it should not be generalized to every browser extension.

Use this decision table before choosing a method. The observations are checks to perform on your page, not results from a hardware test.

| What moves when you scroll? | Likely capture target | What to verify in the saved image |
|---|---|---|
| The whole document | Browser full-page capture | The first and last required sections, plus something in the middle |
| One panel while the surrounding page stays put | That panel’s scrolling content | The bottom row inside the panel, separately from the page footer |
| Inspecting the page structure shows old row elements being replaced during scrolling | A virtualized list | Every required row identifier; apparent image height proves little |
| Content moves but a toolbar stays fixed | A region containing moving and stationary content | Repeated headings, missing lines, and joins around the toolbar |

Move the pointer inside the panel and scroll a little. Then try outside it. Record which content responds. This is a quick way to decide what you need to capture before spending time configuring a tool.

## A bigger element can still contain fewer rows

Virtualized interfaces render a moving subset of a list. Google’s [explanation of list virtualization](https://web.dev/articles/virtualize-long-lists-react-window) describes recycling or replacing page elements as they leave the visible region.

The practical implication is that expanding a panel’s CSS height does not, by itself, prove that all its records exist in the rendered page. A layout change may trigger more rendering, or it may leave gaps. The application decides.

Keep that distinction in the handoff. If you temporarily expand a panel for a reference image, label the result as an expanded view. It may be useful for reading the data, but it no longer demonstrates the original clipping or scroll behavior.

For a bug report about a clipped button, retain the original viewport. For a complete list of records, look for the application’s export or print view and verify its scope. Those are different deliverables even when they start from the same screen.

## Check the seams in a scrolling capture

Shottr’s current [scrolling-capture guide](https://shottr.cc/kb/scrollingcapture) documents several concrete failure conditions: moving content can disrupt frame matching; fixed elements can repeat; and automatic capture can struggle with apps such as Terminal and VS Code. It recommends manual mode for non-native scrolling and explains that scrolling too quickly can leave gaps.

Treat those as documented Shottr limitations, not a verdict on every Mac capture utility. They explain why a plausible-looking image needs a content check. A repeated toolbar is visible. A missing block between similar-looking rows may be easier to overlook.

## Try a numbered-content check

Use a disposable document or a non-sensitive sample of the workflow you need to capture. This is a proposed reader exercise; no benchmark results are claimed here.

1. **Define the range.** Prepare 40 rows labeled `Row 01` through `Row 40`, with visibly different text at rows 10, 20, and 30. If you cannot edit the content, use existing unique identifiers and write down the expected range.
2. **Fix the view.** Keep the window size, browser zoom, and panel width unchanged. Note the app and capture-tool versions.
3. **Capture the panel.** Choose a method that targets its scrolling content. Preserve the unedited output before cropping or annotating.
4. **Inspect the sequence.** Find the first row, last row, and each checkpoint. Then inspect the joins and verify all 40 labels appear once, in order. Endpoints alone cannot establish completeness.
5. **Change one variable if it fails.** For a stitched capture, try slower scrolling. For a clipped panel, change the target or capture method. Keep both files so the difference remains visible.

Use two columns in your notes: “expected identifiers” and “identifiers found.” A file containing rows 01–12 and 20–40 has 33 of the expected 40 rows. It is incomplete even if the join looks clean. That is example arithmetic, not an observed tool failure.

Research scope: documentation retrieved September 19, 2026, plus the two deliberately selected reports above. The reports concern screenshot libraries, not a representative sample of Mac users; their causes cannot be assigned to another app without checking it.

When sharing the result, state the range you verified: “Rows 01–40 checked; panel captured separately from the surrounding dashboard.” If only the endpoints were checked, say that instead.

## Disclosure

Ali owns LazyScreenshots. That creates a conflict when he writes about LazyScreenshots or reviews competitors, so relevant pieces say so plainly. These articles are research and opinion, not independent third-party ratings.