Full-Page vs Viewport Screenshots: When to Use fullSize (and When Not To)

fullSize is a one-word flag, but it changes what a screenshot is actually for. Set it wrong and you either miss the content that mattered, or hand someone a five-screen-tall image when they only wanted the hero section. It is worth being deliberate about, rather than copy-pasting whatever the last script used.

What fullSize Actually Does

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://example.com/pricing",
    "format": "png",
    "width": 1440,
    "height": 900,
    "fullSize": true
  }'

With fullSize: false (the default), the capture is exactly the width × height viewport you requested — what a visitor sees before scrolling. With fullSize: true, the renderer scrolls the entire page and stitches it into one tall image, regardless of the height value.

When Viewport-Only (fullSize: false) Is Right

• Social previews and OG images. These render in a fixed card size — a full-page capture would just get cropped anyway.
• App store and marketing assets. Store listings expect a specific, exact frame, not a scrolled composite. See Capturing Perfect App Store and Google Play Screenshots at Scale.
• Above-the-fold monitoring. If you only care whether the hero, nav, or a specific widget rendered correctly, a full-page capture just adds noise (and load time) to a comparison.
• Device-preset asset generation. Matching a known width/height exactly, as covered in Emulating iPhone, Android, and Tablet Screens, assumes a fixed frame, not a scrolled one.

When Full-Page (fullSize: true) Is Right

• Release and QA reviews. A regression three screens down the page is invisible in a viewport-only capture. Full-page is the default recommendation for visual diff and release review workflows.
• Compliance and archival captures. If the point is proving what a page said in full at a point in time, a partial capture is not evidence of anything.
• Long-form content QA. Blog posts, documentation, and pricing pages with FAQ sections need the whole page reviewed, not just what fits above the fold.

The Trade-Off Nobody Mentions: Noise in Diffs

Full-page captures of dynamic pages pick up more moving parts — a footer with a rotating testimonial, lazy-loaded images further down, a chat widget that shifts position. Every one of those adds potential mismatch noise to a v3/compare call. If a full-page diff comes back noisier than expected, it is often worth checking whether the extra length is actually adding signal, or just picking up content nobody was trying to monitor. Tuning the threshold Parameter in the Visual Diff API covers how to compensate for that without switching back to a partial capture.

A Simple Default

If in doubt: use fullSize: true for anything a human will review for correctness, and fullSize: false for anything that renders into a fixed-size frame somewhere else (a card, a store listing, a social preview). Getting this one flag right up front avoids re-running a whole capture pipeline later because the images were the wrong shape for the job.

Both modes run through the same Snapshot Site endpoint — switching between them is a one-field change, not a different integration.