Key takeaways
- Viewport width chooses the responsive layout; full-page height chooses how much of it is captured.
- Lazy content needs a bounded scroll and wait policy, not an unlimited delay.
- Very tall pages are often more useful to vision models as ordered overlapping slices.
Viewport size and capture height are different controls
The viewport determines the responsive layout a page chooses. Capture height determines how much of the resulting document appears in the image. A 390-pixel-wide mobile viewport can still produce a very tall full-page screenshot, while a 1440-by-900 desktop viewport can capture only the visible fold.
Set the viewport first so navigation, columns, images, and breakpoints render as intended. Then decide whether the workflow needs the visible viewport or the complete document.
| Mode | Best for | Main tradeoff |
|---|---|---|
| Viewport | Visual regression, above-the-fold checks, thumbnails | Content below the fold is intentionally omitted. |
| Full page | Audits, archiving, AI visual analysis | Tall pages cost more memory and can be difficult to inspect as one image. |
| Bounded slices | Vision models and very long documents | The client must retain ordering and overlap metadata. |
Lazy content makes “finished” ambiguous
Many sites load images or application data only when content approaches the viewport. A browser can report that the initial network is idle while elements farther down the page have never been requested.
A renderer needs a documented policy: capture immediately after the chosen load state, perform a bounded scroll pass, or wait for a small explicit delay. Unlimited scrolling and open-ended waits are dangerous because a malicious or broken page can extend forever.
- Use a bounded navigation timeout.
- Cap any post-load delay.
- Limit the number and distance of scroll steps.
- Enforce a maximum full-page height and artifact size.
Fixed headers and overlays can repeat or hide content
Sticky navigation, cookie banners, chat widgets, and interstitials can obscure a large portion of a screenshot. Some capture techniques also repeat fixed elements as the page is stitched.
Prefer the browser engine’s native full-page capture where possible. If blocking options are offered, keep them explicit and conservative. Removing every element that resembles an overlay can damage legitimate page content and make the screenshot less faithful.
Choose the image format for the downstream task
PNG preserves sharp interface text and transparency but can be large. JPEG is compact for photographic pages but introduces artifacts around text. WebP often balances size and quality when the consuming system supports it.
For AI analysis, dimensions and byte limits matter as much as format. A single extremely tall image may be resized so aggressively that small text becomes unreadable. Overlapping bounded slices are often a better later-stage workflow than an unbounded image.
A dependable full-page capture checklist
- Choose the viewport that matches the desired responsive breakpoint.
- Specify full-page capture rather than inferring it from viewport height.
- Use bounded load-state and delay options.
- Record final URL, dimensions, byte size, format, and timing.
- Fail explicitly when the document exceeds the service height or byte limit.
- Use private, expiring delivery for pages that may contain sensitive information.
Why is a full-page screenshot extremely narrow or unreadable?
The viewport width may not match the intended breakpoint, or the final image may be so tall that the viewer scales it down. Use an explicit viewport and consider bounded slices for very long pages.
Does network idle mean every lazy image is loaded?
No. Content that loads only after scrolling may never be requested during the initial navigation, even when the current network is idle.
Review the screenshot job contract.
See the proposed request fields, job states, failure model, and private-artifact response.
Read the docs →