Full Page Screenshot API: How to Capture Entire Web Pages in 2026

A full page screenshot API captures the entire height of a web page in a single image, not just the part that fits inside the browser window. Instead of getting back only the visible viewport, you get a tall image that includes everything a user would see if they scrolled from the top of the page all the way to the footer. This guide explains how a full page screenshot API works, how it differs from a standard viewport capture, which parameters matter most, and how to call one from your own code today.

What a Full Page Screenshot API Captures

When you load a page in a browser, you only see a window-sized slice of it, the viewport. A typical viewport screenshot is 1280x720 pixels and stops at the fold. A full page capture is different: the API measures the full rendered height of the document, including content far below the fold, and returns one continuous image of the whole thing.

This matters whenever the valuable content lives below the fold: long landing pages, blog articles, pricing tables, dashboards, and search results. A viewport screenshot of a 6000-pixel-tall article would show only the first 720 pixels. A full page screenshot API returns all 6000 pixels in one image.

With CaptureAPI, full-page mode is a single boolean flag on the same endpoint you already use for viewport captures:

curl "https://captureapi.dev/api/v1/screenshot?url=https://example.com&fullPage=true&format=png" \
  -H "X-API-Key: cap_your_api_key_here" \
  -o full-page.png

Setting fullPage=true tells the service to keep capturing past the viewport boundary until it reaches the bottom of the document.

Full Page vs. Viewport: When to Use Each

Both modes use the same rendering pipeline; they differ only in how much of the page they capture. Choosing correctly keeps your images relevant and your payloads small.

• **Use a viewport capture** for thumbnails, link previews, social cards, and any case where the above-the-fold hero is what matters. Output is predictable and small.
• **Use a full page capture** for archiving complete pages, visual regression testing of long layouts, capturing entire articles or reports, and monitoring pages where changes happen below the fold.

A practical rule: if you need to prove what an entire page looked like at a point in time, use full page. If you need a representative preview, use the viewport.

How a Full Page Screenshot API Works Under the Hood

Capturing a full page reliably is harder than it looks, which is exactly why a managed API is useful. Behind a single fullPage=true request, the service handles several tricky steps:

• **Render the page**: A Chromium-based browser loads the URL, executes JavaScript, and applies CSS so the layout matches what a real user sees.
• **Trigger lazy content**: Many pages load images and sections only as you scroll. The API scrolls the page programmatically so lazy-loaded media and infinite-scroll content render before capture.
• **Measure the true height**: Once the page settles, the service reads the full document height rather than the window height, so nothing below the fold is cut off.
• **Stitch or capture in one pass**: The browser produces a single tall image covering the entire measured height, encoded as PNG, JPEG, or WebP.
• **Return the result**: The image streams back in the response, or a hosted URL is returned as JSON so you can store it.

Doing this yourself with raw Puppeteer or Playwright means writing your own scroll-and-wait logic, handling fonts, and managing memory for very tall pages. A full page screenshot API absorbs that operational work.

Parameters That Matter for Full-Page Captures

Full-page mode interacts with a few options more than viewport mode does. Tuning these prevents blank sections and clipped content:

• **Wait conditions**: Wait for network idle or for a specific CSS selector so dynamic content finishes loading before the capture begins.
• **Width**: You still set the viewport width, which controls the responsive layout. The height is determined automatically by the document.
• **Delay**: A short fixed delay can help pages with animations or fonts that pop in after load.
• **Format and quality**: PNG keeps text crisp for archiving; JPEG or WebP at a sensible quality keeps very tall images small enough to store cheaply.

You can see every supported parameter and try them interactively before writing code in the [screenshot API documentation](/docs/screenshot) and the live [API playground](/playground).

Integrating a Full Page Screenshot API in Code

The integration is intentionally small: build a URL, set fullPage=true, attach your key, and read the binary response. Here is a reusable JavaScript helper:

// JavaScript / Node.js
async function captureFullPage(url, options = {}) {
  const params = new URLSearchParams({
    url,
    fullPage: "true",
    width: String(options.width || 1280),
    format: options.format || "png",
  });

  const response = await fetch(
    `https://captureapi.dev/api/v1/screenshot?${params}`,
    { headers: { "X-API-Key": process.env.CAPTURE_API_KEY } }
  );

  if (!response.ok) {
    throw new Error(`Capture failed: ${response.status}`);
  }
  return Buffer.from(await response.arrayBuffer());
}

The same request from Python is just as short:

# Python
import os
import requests

def capture_full_page(url, width=1280, fmt="png"):
    response = requests.get(
        "https://captureapi.dev/api/v1/screenshot",
        params={"url": url, "fullPage": "true", "width": width, "format": fmt},
        headers={"X-API-Key": os.environ["CAPTURE_API_KEY"]},
        timeout=60,
    )
    response.raise_for_status()
    return response.content

Notice the longer client-side timeout in the Python example: very tall pages take longer to render and encode, so give the request room to finish.

Common Pitfalls and How to Avoid Them

A few issues come up repeatedly with full-page captures, and each has a simple fix:

• **Blank lower sections**: Caused by lazy-loaded images that never triggered. Add a wait-for-network-idle condition or a short delay so scrolling can load them.
• **Enormous file sizes**: A 10,000-pixel PNG can be heavy. Switch to WebP or JPEG with moderate quality for archived captures where pixel-perfect text is not required.
• **Layout shift mid-capture**: Sticky headers or cookie banners can overlap content. Where supported, hide or wait for these elements before capturing.
• **Timeouts on huge pages**: Increase your client timeout and rely on the API's managed wait conditions rather than a single fixed delay.

For a broader foundation on how the underlying service operates, read [what a screenshot API is and how it works](/blog/what-is-a-screenshot-api), and to run captures on a schedule see [how to automate website screenshots with an API](/blog/automate-website-screenshots-with-api).

Performance and Storage Considerations

Full-page captures are heavier than viewport captures in three predictable ways, and planning for them keeps your pipeline fast and your storage bill sane. First, rendering takes longer because the service must scroll the whole document and wait for lazy content, so very tall pages can take several seconds rather than a few hundred milliseconds. Second, the output image is physically larger: a page that is ten times the viewport height produces an image roughly ten times the size, which affects both bandwidth and storage. Third, encoding a large image consumes more memory and CPU on the rendering side, which is one more reason to let a managed service handle the work instead of running your own browser fleet.

A few habits keep full-page workloads efficient. Cache captures that do not change often instead of re-rendering identical pages on every request. Choose WebP or moderately compressed JPEG for archives where pixel-perfect text is not essential, and reserve PNG for captures you need to read precisely. Finally, capture only the width you actually need, since a narrower viewport produces a shorter, lighter image on responsive layouts. These choices matter more on full-page jobs than on viewport thumbnails, where every image is already small and fast.

Frequently Asked Questions

What is a full page screenshot API?

A full page screenshot API is a hosted service that captures the entire height of a web page, not just the visible viewport. You send a URL with a full-page flag and the API returns one continuous image covering everything from the top of the document to the footer.

How is a full page capture different from a viewport screenshot?

A viewport screenshot captures only the window-sized area visible without scrolling, usually around 1280x720 pixels. A full page capture measures the entire document height and returns all of it in a single tall image, including content below the fold.

Why do some full-page screenshots have blank areas?

Blank sections usually come from lazy-loaded images or infinite-scroll content that never rendered. Adding a wait-for-network-idle condition or a short delay gives the API time to scroll the page and load that content before capturing.

How do I take a full page screenshot with an API?

Create a free API key, then send a single GET request with your target URL and the full-page flag set to true. You can test the parameters interactively in the [API playground](/playground) and review them all in the [screenshot API documentation](/docs/screenshot), or learn more on the [screenshot API overview](/screenshot-api).

Conclusion

A full page screenshot API turns the messy work of scrolling, waiting for lazy content, and measuring true document height into a single HTTP request with one extra flag. Use viewport captures for previews and full-page captures whenever the whole page is the point, archiving, regression testing, or below-the-fold monitoring. Create a free key, capture your first full page in minutes through the [screenshot API docs](/docs/screenshot), and explore the [screenshot API overview](/screenshot-api) to see every capture option.