Capture the whole page, not the part that fits

Some things only make sense whole. A design spec where the argument is about vertical rhythm. A Slack thread where the third message is the one that matters and the first is the one that gives it context. A stack trace forty lines long. A pricing table someone needs to compare top to bottom. Split any of those across five screenshots and the reader has to reassemble them, in order, from an email or a chat where the order is not guaranteed.

Scrolling capture produces one file instead. You select it from the capture menu — or press ⌃⌘L — then either scroll the content yourself and click Capture frame at each step, or let auto-scroll drive it with synthetic scroll events. Auto-scroll needs the macOS Accessibility permission and falls back to the manual mode if you decline it, and it stops at a hard ceiling of 40 frames. Either way SnapShelf stitches the frames it collected into a single tall image. The output is an ordinary PNG — it drops into a ticket, a document, or a message like any other capture, and it flows through the same auto-filing rules and lands in the same searchable gallery.

The pace matters more than anything else you control. Scroll steadily and moderately rather than in fast flicks. Momentum scrolling on a trackpad can skip content between frames faster than it can be captured, and the stitcher can only work with what it saw.

A stitched screenshot is an inference, not a recording. The app sees a sequence of overlapping frames and has to work out how far the content moved between each one, then join them without duplicating or dropping a band of pixels. When the page is static text this is reliable. When the page fights back, it is not, and it is worth knowing which pages fight back before you rely on it.

Sticky headers and floating navigation bars are the classic case: an element that stays in place while everything behind it moves appears repeatedly down the stitched image. SnapShelf has no sticky-header handling — there is no detection step that notices the fixed bar and removes it, so plan on hiding it yourself. Lazy-loaded content is the second, and it fails in a way worth understanding: the capture ends when two consecutive frames look identical, so an image that has not finished painting reads as "nothing moved, we must be at the bottom" and the capture stops early. Infinite-scroll feeds have no bottom to reach. Elements that animate on scroll are captured mid-animation, at whatever state they happened to be in. Stitching works by matching row signatures where frames overlap, which is why steady, non-overlapping scrolling gives much better joins than flicks.

SnapShelf works with web pages, documentation, long Notion pages, code files, and most macOS apps that use standard scrollable views. That last clause is the honest boundary — an app that draws its own custom scrolling surface is a harder target than one using the standard system machinery, and results will vary. Scrolling capture also depends on the macOS Accessibility permission, the same one used for window-title routing and cursor auto-zoom.

When a page does defeat the stitcher, the fallback is usually to collapse the problem rather than fight it: hide the sticky header with the browser’s reader mode, scroll once slowly to force lazy content to load and then scroll back up and capture, or zoom the page out so more fits per frame.

macOS has no scrolling capture. ⌘⇧5, ⌘⇧4, and ⌘⇧3 all capture what is currently on the display and nothing beyond it. There is no system-level full-page mode and no hidden flag that enables one.

Your browser, however, probably does — and for web pages specifically it is the better tool, so use it. In Safari, open the Web Inspector with ⌥⌘I, right-click the topmost html node in the Elements tab, and choose Capture Screenshot: you get the entire page rendered by the browser itself, not stitched. Chrome’s equivalent lives in the Command Menu — open DevTools, press ⌘⇧P, and type "screenshot" to find "Capture full size screenshot". Firefox has it in the right-click context menu directly.

Those produce genuinely better results for web content than any stitching approach, because the browser renders the full page in one pass and there is nothing to infer. They also handle sticky headers correctly, which stitching struggles with. The catch is that they only work in a browser. For a Notion page in the desktop app, a long file in your editor, a Slack thread, a Terminal buffer, or a native macOS app, DevTools is not available and stitching is the only option there is.

Shottr does, and it is free. If scrolling capture and fast still screenshots are your entire requirement, Shottr is an excellent tool that costs nothing, and it also brings pixel-measurement and design-inspection features SnapShelf does not have. It does not record the screen, export GIFs, edit video, or auto-file.

CleanShot X does scrolling capture as part of the deepest capture toolkit in this comparison, at $29 one-time plus $19/yr to keep receiving updates (verified July 2026, subject to change), and it has cloud share links SnapShelf does not offer. Snagit has scrolling capture too, with years of refinement in step-capture and documentation workflows, on a $39/yr subscription since 2025.

Xnapper ($17) and CaptureShelf ($15) do not do scrolling capture — the first beautifies, the second organises. SnapShelf’s version is not a differentiator on its own; it is table stakes for a capture tool, and the reason to have it here is that the tall image it produces gets auto-filed, annotated, OCRed, or sent to Claude Code without moving to another app.