Capture a very long page without one unusable image
A 40,000 pixel screenshot is technically one file and practically nothing you can open, send or diff.
full_pagefull_page_slicesfull_page_slice_heightfull_page_slice_overlap_heightfull_page_max_heightfull_page_algorithmcurl --fail-with-body "https://api.pagecapture.dev/v1/take" \
-H "X-Access-Key: $PAGECAPTURE_KEY" \
-H "Content-Type: application/json" \
--data '{"url":"https://example.com","format":"jpg","full_page":true,"full_page_slices":true,"full_page_slice_height":2000,"full_page_slice_overlap_height":40}' \
-o capture.jpgVerified 2026-08-13 by running the published code against a fixture.
Configure it in the playgroundWhat it does
- Renders the document in sections and returns the stitched image as the response body, exactly as a normal full-page capture does.
- Also returns the individual slices when `full_page_slices` is on, so you can page through a long capture instead of scrolling one enormous file.
- Stops at `full_page_max_height` when you set one, which is the honest way to bound an infinite feed.
What it does not do
- Does not slice forever. Section rendering stops after 60 slices — a page that needs more is pathological, and the guard exists so one target cannot occupy a worker indefinitely.
- Does not load lazy content by itself. Scrolling the page first is `full_page_scroll`, which is a separate parameter and a plan entitlement.
- Does not change the response shape. The body is still one image; the slices are additional artifacts.
Every limit on this page is the one the API enforces
These rows are read from the same parameter table that validates your request. Nothing here is transcribed, so a number cannot drift from the behaviour it describes.
| Parameter | Type | Default | Range | Endpoints | Cache key |
|---|---|---|---|---|---|
full_pageCapture the entire scrollable document. | boolean | false | — | /v1/take | In |
full_page_slicesReturn the page as several stitched slices instead of one image. | boolean | false | — | /v1/take | In |
full_page_slice_heightHeight of each slice. | integer | 4000 | 1 – 16,000 | /v1/take | In |
full_page_slice_overlap_heightOverlap between consecutive slices. | integer | 0 | 0 – 2,000 | /v1/take | In |
full_page_max_heightStop the capture at this document height. | integer | — | 1 – 60,000 | /v1/take | In |
full_page_algorithmFull-page strategy: one capture of the whole document, or section-by-section for very tall pages. | enum | default | — | /v1/take | In |
How it behaves next to the rest of the request
full_page_slice_overlap_heightOverlap between consecutive slices.
Overlap up to 2,000 px between consecutive slices. Without it, a line of text that lands exactly on a boundary is cut in half in both slices.
full_page_algorithmFull-page strategy: one capture of the whole document, or section-by-section for very tall pages.
`by_sections` renders section by section rather than as one surface. It is the strategy that makes a very tall document possible at all, and slicing builds on it.
full_page_scrollScroll through the page first so lazy content loads.
Lazy images only load when something scrolls past them. This is the parameter that does the scrolling, and it requires the scrolling-screenshots entitlement.
Errors this option can produce
resulting_image_too_largeHTTP 400The resulting image exceeds the maximum allowed size.
timeout_errorHTTP 500 · retryableThe capture did not complete within the allowed time.
None of them is billable. No error code in the catalog is.
Related capabilities
All capabilities100 successful captures a month, every feature unlocked, no card.
Get an API keyPageCapture Engineering · reviewed by PageCapture API maintainers · Verified 2026-08-13 by running the published code against a fixture.