Clioos › Guides › Website Screenshots

How to Capture a Full Web Page

By Clioos 团队

A viewport screenshot only shows the top of the page — everything below the fold is missing. Full-page capture is a different job: the renderer scrolls the page step by step to trigger lazy loading, waits for the document to settle, then screenshots the whole document as one tall image. With Shot that is one parameter, full_page: true (it is already the default). On 2 November 2026 a real long guide page rendered as a single 1280x3868 PNG in 3,058 ms.

At a glance

Full page means the whole document, not the viewport: Shot scrolls step by step to trigger lazy loading before capturing.
The worked example below is a real render, not a mock: 1280x3868 PNG, 617,531 bytes, X-Render-Ms 3,058, cache MISS.
Tall pages get tall files: a 3,868-pixel page at 1280 wide is about 4.95 million pixels at scale 1 — fine — but the same page at scale 2 is about 19.8 million pixels and breaks Shot's 16,000,000-pixel cap.
Full-page renders take longer than viewport renders and count the same against quota: 20 a day per key, 50 a day per IP, cached renders free within the 1-hour cache.
Sticky headers, infinite scroll and lazy-loaded ads can still distort a full-page shot — check the bottom of the image, not just the top.

Steps

Get a free API key at https://clioos.com/shot/ (email code or Google sign-in; 20 renders a day per key, no credit card while the probe runs).
POST with full_page true: curl -X POST https://clioos.com/shot/v1/screenshot -H "Authorization: Bearer YOUR_KEY" -H "Content-Type: application/json" -d '{"url": "https://example.com/your-long-page", "full_page": true, "width": 1280, "height": 800}' --output fullpage.png. The width sets the page width; the height is only the initial viewport height — the final image height is set by the page itself.
Watch the pixel cap on long pages: width x height x scale squared must stay under 16,000,000. For a page around 3,868 pixels tall at 1280 wide, scale 1 is about 4.95 million pixels (fits) but scale 2 is about 19.8 million (rejected with 400). If you hit the cap, drop device_scale_factor to 1 or capture the page in sections with a CSS selector.
If sections come out blank, add delay: "delay": 2 gives two extra seconds after load for late content. If the page is infinite-scroll, full-page capture will still end somewhere — it captures the document as loaded, not an endless feed, so set expectations accordingly.
Verify before publishing: open the PNG, check the top, middle and bottom, and confirm the footer rendered. Repeating the identical request within an hour returns a cache HIT and does not consume quota — use that for re-downloads, not re-renders.

Worked example (tested 2 November 2026)

Method, disclosed in full: same server-side test key as the companion screenshot guide (created directly in the Shot database because the public key flow needs an email verification code in a browser; renders called against the local service at 127.0.0.1:8091, the same service behind clioos.com/shot/; test key revoked after the run). Target: a real long page, the live guide at https://clioos.com/guides/pdf/how-to-convert-pdf-to-excel.html, requested with full_page true at 1280x800.

Measure	Result
HTTP status / format	200, image/png
Image size	1280 x 3,868 pixels — the height is the page's own height, not the 800 requested (800 is only the initial viewport)
File size	617,531 bytes
Render time	X-Render-Ms 3,058; wall time 3,147 ms; X-Cache MISS (first render, so it consumed one daily render)
Quota after	X-RateLimit-Remaining 18 — two fresh renders in the run, two quota units spent
Pixel arithmetic	1280 x 3,868 = 4,951,040 pixels at scale 1 (under the 16,000,000 cap); at scale 2 it would be 19,804,160 (over the cap, rejected)

Compare with the viewport render of example.com in the companion guide (1280x800, 70,115 bytes, 2,482 ms): the full-page render is about 8.8 times larger in bytes and about 576 ms slower, because it scrolls, waits for lazy content, and encodes a much taller image. Budget quota and time accordingly — a full-page shot is not a free upgrade over a viewport shot.

What it can't do

Infinite scroll has no end: a feed that keeps loading will not produce an infinite image. Full-page capture renders the document as loaded after scrolling and settling — set a cutoff in your own workflow if you need one.
Sticky elements can repeat or smear: fixed headers and footers are designed for a viewport, not a 3,868-pixel document. They may appear once, repeat, or overlap content in a tall capture — inspect the middle of the image, not just the top.
Lazy loading is triggered, not guaranteed: Shot scrolls step by step to trigger lazy loading, but content that loads only on real user interaction (clicks, hovers, logins) still will not appear. Shot accepts no cookies or custom headers, so logged-in content is out of reach.
Pixel cap bites on long pages: width x height x scale squared must stay under 16,000,000. Long pages at retina scale 2 are the first thing to hit it — the fix is scale 1, a narrower width, or section captures via selector.
30-second timeout: very long or heavy pages can hit the 30-second hard timeout (504) before the scroll-and-settle pass finishes. Split such pages with a selector, or accept a viewport shot.
Private pages are blocked: same as any Shot render — private IPs, localhost and metadata endpoints return 422.

Viewport vs full page: when to use which

Viewport (full_page false): use for above-the-fold checks, social previews, and quick regression checks. Smaller files, faster renders, same quota cost.
Full page (full_page true): use for archiving a whole article, documenting a long landing page, or checking a page's full layout. Expect taller files and slower renders.
Element (selector): use when only one card, chart or hero section matters — it sidesteps the pixel cap and the tall-file problem entirely.

Other names for the same job

People describe this job in different words. To screenshot entire webpage content as one tall image is the same task as full-page capture above: scroll, settle, capture the whole document. A full-page screen grab is also the same thing — just shorter wording for the same output. If a tool only offers a viewport shot, it cannot do this job no matter what it calls the button.

Frequently asked questions

Is full_page true the default in Shot?

Yes. The API default for full_page is true, but set it explicitly in your request so the intent is clear and a future default change cannot silently alter your output.

Why is my full-page image taller than the height I requested?

Height is only the initial viewport height. In full-page mode the final image height is set by the page document itself — a long page produces a tall image, as in the worked example (requested 800, delivered 3,868).

Why did a long page fail at device_scale_factor 2?

The pixel cap: width x height x scale squared must stay under 16,000,000. A 1280x3868 page at scale 2 is about 19.8 million pixels, so it is rejected with 400. Use scale 1 or capture in sections.

Does a full-page render cost more quota than a viewport render?

No — one fresh render costs one daily render either way (20 a day per key, 50 a day per IP). But full-page renders take longer, so they are more likely to approach the 30-second timeout on heavy pages.

What if the bottom of my full-page screenshot is blank?

That section did not load during the scroll-and-settle pass. Try delay 2-5 seconds, then re-render. If it still fails, the content likely needs interaction or login, which Shot cannot do.