ScreenshotAPI vs Puppeteer for Full-Page Website Screenshots
Compare ScreenshotAPI and Puppeteer for full-page screenshots, with runnable code, setup tradeoffs, pricing context, and a hosted alternative.
For full-page website screenshots, use Puppeteer when you need to control the browser and its workflow in your own application. Use ScreenshotAPI when you want a hosted capture endpoint with documented full-page options. Puppeteer requires you to run and operate browser automation; ScreenshotAPI shifts that work to a service. Neither choice is a universal winner for speed, reliability, fidelity, or total cost: compare them against your pages, required interactions, deployment, and budget.
If you want a hosted API, ScreenshotNeo is the first alternative to try: it removes cookie banners, popups, and chat widgets before capture, bills only clean shots, and has the lowest paid plan described here.
How the two approaches differ
| Consideration | Puppeteer | ScreenshotAPI |
|---|---|---|
| Where capture runs | In your application or infrastructure, using a browser automation workflow. | Through a hosted screenshot API. |
| Full-page setting | Set fullPage: true; the documented default is false. |
Full-page images are among the documented capture features. |
| Browser control | Useful when your workflow needs browser actions, navigation waits, or element screenshots. | Offers configurable capture options; do not assume every browser action maps to an API option. |
| Operations | You are responsible for running and maintaining the browser workflow. | The provider operates the capture service; your application makes API requests. |
| Cost basis | Estimate your own hosting and engineering costs. | Check the current plan and per-shot terms before using it. |
Puppeteer’s official API documents the fullPage option and its default. Its guide shows navigation followed by a readiness wait and screenshot, and also documents element-level screenshots. ScreenshotAPI’s documentation advertises full-page output and configurable options. These are vendor documentation claims, not results from an independent feature-parity test. [Puppeteer ScreenshotOptions] [Puppeteer screenshots guide] [ScreenshotAPI documentation]
Take a full-page screenshot with Puppeteer
This runnable Node.js example opens a page, waits for navigation to reach networkidle2, captures the full page as a PNG, and closes the browser even if navigation or capture fails. Install Puppeteer in a Node.js project first with npm install puppeteer. The package manages a compatible browser installation as part of its normal setup.
const puppeteer = require('puppeteer');
async function main() {
const browser = await puppeteer.launch({ headless: true });
try {
const page = await browser.newPage();
await page.setViewport({ width: 1440, height: 900 });
await page.goto('https://example.com', {
waitUntil: 'networkidle2',
timeout: 60000,
});
await page.screenshot({
path: 'page.png',
type: 'png',
fullPage: true,
});
} finally {
await browser.close();
}
}
main().catch((error) => {
console.error(error);
process.exitCode = 1;
});Save it as screenshot.js and run node screenshot.js. Replace the example URL with a page you are authorized to capture. For current API details, see the ScreenshotOptions reference and screenshots guide.
Readiness and page setup
waitUntil: 'networkidle2' is a navigation condition shown in Puppeteer’s guide. It can be a useful starting point, but it does not prove that every visual element is ready: pages can load content later, and some sites keep network connections open. For a page with known asynchronous content, wait for a page-specific selector or condition after navigation, then capture. Choose a timeout that fits your workload and handle timeouts explicitly rather than silently saving a partial result.
Set the viewport before navigation or capture so responsive layout uses the intended dimensions. If a page needs authentication, consent handling, clicks, or other setup, implement those steps in the browser workflow before calling screenshot(). For a single component, Puppeteer also supports an element screenshot via ElementHandle.screenshot(); full-page capture is the appropriate option when you need the whole document.
Relevant Puppeteer screenshot options
fullPage: set totrueto capture beyond the viewport; it defaults tofalse.path: write the result to a file. Omit it when you want the screenshot returned as a buffer.type: choose a supported image format, such as PNG or JPEG. Check the current API reference for format-specific options.quality: relevant to lossy formats such as JPEG; it does not apply to PNG.clip: capture a defined rectangle when you need a region instead of the whole page. Check current API constraints before combining it with other sizing options.omitBackground: useful when a supported output and page setup require transparency; verify behavior for the format you choose.captureBeyondViewport: a lower-level option for capture outside the viewport; the API documents its interaction with full-page capture.
Option availability and interactions can change between Puppeteer versions. Consult the current official reference rather than assuming settings from another release apply unchanged.
Call ScreenshotAPI for a full-page capture
ScreenshotAPI documents full-page screenshots as a hosted capture feature. Its documentation also advertises image formats including JPEG, PNG, and WebP, as well as PDF output, custom CSS or JavaScript, geolocation, GET and POST integration, and a fresh=true option to request a current result instead of a cached screenshot. Check its current documentation for exact parameter names, authentication, response handling, and option compatibility before deploying.
The research material does not provide a verified endpoint and parameter set suitable for a runnable request here, so this article does not guess one. Use the vendor’s official documentation for a request matching your account and capture options.
Choose based on the work you need to own
Choose Puppeteer when
- You need browser actions or custom page setup that you want to implement directly.
- You want screenshots as one step in a larger browser automation workflow.
- You can operate the browser process, manage failures, and scale the workload in your own environment.
Choose a hosted API when
- You prefer an HTTP integration over managing browser automation infrastructure.
- The provider’s documented capture options cover your actual requirements.
- You have checked how the service handles authentication, dynamic content, caching, errors, and the output format you need.
Feature lists alone do not establish equivalent behavior. Test representative pages, including late-loading content, authenticated pages, and interactions your workflow needs. The available sources contain no controlled comparison of ScreenshotAPI and Puppeteer on dynamic pages.
Pricing, performance, and reliability
Pricing
ScreenshotAPI’s pricing page states an offer of the first 100 shots free, then $0.001 per shot, and displays volume packages. This is a vendor-published offer that can change; verify the current terms before relying on it. That per-shot figure is not a total-cost comparison with Puppeteer. For Puppeteer, account for infrastructure, browser operation, engineering time, and the workload you expect. The sources do not establish a universal cheaper option. [ScreenshotAPI pricing]
Performance
No benchmark in the available research establishes which option captures pages faster. Puppeteer performance depends on your browser environment, pages, waits, and concurrency. A hosted service’s result depends on its service and capture settings. Measure representative URLs under the conditions you will use, including cold and cached requests where relevant, and compare the returned image for completeness as well as elapsed time.
Reliability
With Puppeteer, close browser instances reliably, set navigation and operation timeouts, and record which stage failed. For a hosted service, inspect HTTP status, response body, and provider-specific error details, and understand its cache and retry behavior. In either case, use bounded retries for transient failures and avoid retrying indefinitely when a page consistently times out or blocks automation.
Common problems and fixes
| Symptom | Likely cause | What to do |
|---|---|---|
| Only the visible viewport is saved | fullPage was omitted or set false. |
Set fullPage: true and check the installed Puppeteer version’s API. |
| Screenshot is blank or content is missing | Capture ran before client-side content finished rendering, or navigation did not reach the expected state. | Wait for a page-specific selector or condition after navigation; inspect console errors and the page state. |
| Navigation times out | The site is slow, keeps network requests active, or cannot be reached from the runtime. | Check connectivity and the URL, select a suitable readiness condition, and set a deliberate timeout. Do not treat a timeout as a successful complete capture. |
| Browser fails to launch in a deployment | The runtime may lack browser dependencies or have restrictions that differ from local development. | Use a supported environment, install required dependencies, and review Puppeteer’s current deployment guidance. |
| Full-page image is unexpectedly large | The document is very tall or the selected viewport creates a long layout. | Confirm the intended viewport and output format; consider a targeted element capture if the requirement is a specific section. |
| Hosted API response is cached | The provider returned a stored capture under its cache policy. | Check the current API documentation for cache controls; ScreenshotAPI documents fresh=true for requesting a current result. |
| Hosted API option or request is rejected | Parameter names, authentication, or combinations may be incorrect or unsupported. | Compare the request with the provider’s current documentation and inspect the response error details. |
Or skip the browser setup
ScreenshotNeo provides a website screenshot API and MCP server. Make one GET request to capture a URL; see the ScreenshotNeo API documentation for options and response details.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for free and get 1,000 screenshots a month with no card.
FAQ
Should I use ScreenshotAPI or Puppeteer for full-page website screenshots?
Use Puppeteer when browser control and custom workflow are central. Use a hosted API when its documented options meet your needs and you want to call a service instead of operating browser automation. Validate the choice on your pages.
Can ScreenshotAPI capture a full web page?
Yes. Its documentation advertises full-page image capture. Verify the current request options and output details in its official documentation.
Does Puppeteer capture the full page by default?
No. The documented fullPage default is false, so set it to true for a full-page screenshot.
Which option costs less?
The available information does not establish a universal answer. Compare the hosted service’s current pricing with your own infrastructure and operating costs for Puppeteer.
