Turn a URL into a full-page image or PDF through a real browser. Control the viewport, wait for dynamic content, remove distracting elements, and use the result in your product or workflow without maintaining browser infrastructure.
curl -X POST https://api.prod.ss.snapshot-site.com/api/v1/screenshotx-snapshotsiteapi-key: YOUR_API_KEY
Most screenshot failures are page-state problems rather than HTTP problems. A useful API gives the browser enough context to render the intended viewport, wait for the page, and remove transient interface elements before capture.
Use delay for content that appears after load. For more advanced rendering control, the documented v2 and v3 options include DOM waiting and page cleanup.
Use hideCookie for common consent banners and the hide option on supported endpoints for elements that should not appear in the final image.
Set fullSize when the content below the fold matters, or provide width and height for a consistent viewport capture.
Choose PNG, JPEG, WebP, or PDF according to whether you need visual fidelity, a web-friendly asset, or a document.
Get an API key from the console
POST a URL to /api/v1/screenshot with the output format and viewport you need
Add hideCookie and fullSize for a clean, full-length capture
Use delay, or move to the documented v2 options, when the page needs extra rendering control
A clean, full-length capture with cookie banners removed.
curl --request POST \
--url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
--header 'Content-Type: application/json' \
--header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
--data '{
"url": "https://example.com",
"format": "png",
"width": 1440,
"fullSize": true,
"hideCookie": true,
"delay": 2
}'
Keep the API key on your server and send the same JSON request with the built-in fetch API.
const response = await fetch(
"https://api.prod.ss.snapshot-site.com/api/v1/screenshot",
{
method: "POST",
headers: {
"Content-Type": "application/json",
"x-snapshotsiteapi-key": process.env.SNAPSHOT_SITE_API_KEY!,
},
body: JSON.stringify({
url: "https://example.com",
format: "webp",
width: 1440,
height: 900,
fullSize: true,
hideCookie: true,
delay: 2,
}),
},
);
if (!response.ok) {
throw new Error(`Screenshot request failed: ${response.status}`);
}
const screenshot = await response.json();
A website screenshot API is a service that receives a URL and capture settings over HTTP, opens the page in a browser, and produces an image or PDF. Instead of launching Chromium inside every application or automation job, your code sends a request and consumes the result.
Client-side JavaScript, lazy-loaded images, consent banners, responsive breakpoints, and delayed widgets can all change the final pixels. A useful screenshot API manages the browser lifecycle while giving you control over the page state. The basic POST /api/v1/screenshot endpoint covers common captures; the API documentation explains later endpoint versions, and the website screenshot generator lets you test a URL before writing code.
Reliable capture starts with a precise definition of the desired page state. “Take a screenshot of this URL” leaves several important decisions unresolved.
A viewport screenshot records the page area visible at a specific width and height. It is useful for responsive QA, thumbnails, documentation, and any workflow where the fold matters. Keeping dimensions stable also makes results easier to compare over time.
A full-page screenshot records the scrollable page from top to bottom. In Snapshot Site, the fullSize option selects this behavior. Use it for long landing pages, articles, audit evidence, content archives, and pages where a block below the fold may change. See the dedicated mobile screenshot guide when the intended page state is a phone or tablet viewport.
Modern pages rarely become visually complete at the first load event. A short delay can give asynchronous widgets, fonts, and lazy-loaded images time to settle. Longer waits are not automatically better: unnecessary delay makes every job slower and can allow rotating content to change.
Start with the smallest reliable wait. Move to the documented DOM-waiting controls when a fixed delay is too fragile. Later API versions also support cleanup options such as hiding selectors and running custom JavaScript.
Consent dialogs, chat widgets, promotional overlays, and sticky notices can hide the content you actually need. hideCookie handles common cookie banners. The hide option on supported endpoints lets you provide CSS selectors for known elements.
Treat removal rules as part of the capture specification. Prefer stable IDs or data attributes: broad selectors can erase meaningful content, while generated class names may change after a deployment.
The best format depends on what happens after the capture.
| Format | Good fit | Consideration |
|---|---|---|
| PNG | Visual QA, UI evidence, lossless assets | Larger files than compressed alternatives |
| JPEG | Photographic pages and compact previews | Lossy compression can blur fine UI details |
| WebP | Web previews and storage-conscious workflows | Confirm that every downstream consumer supports it |
| Reports, records, and document-oriented delivery | Treat it as a document rather than an image asset |
A visual comparison pipeline benefits from stable, lossless inputs, while a dashboard showing many thumbnails may value smaller files. The examples above switch formats without changing the integration model.
Marketplaces, bookmarking tools, and internal dashboards can turn submitted URLs into visual previews. Capture on the server and serve a cached asset instead of requesting a new screenshot on every page view.
Documentation teams can record the interface shown in a guide. Content teams can verify that a published page rendered with the intended hero, headings, and calls to action. Screenshots reveal layout problems that raw HTML validation misses.
Scheduled captures create a visual history. To quantify changes rather than only archive images, use the Visual Diff API or a website monitoring workflow. Consistent dimensions, timing, and hidden selectors reduce noise.
A screenshot can become a QA attachment, content-approval record, or scheduled-report asset. The screenshot automation guide covers CI, cron, SDK, and no-code approaches.
Both approaches render pages in a browser, but they place operational responsibility in different places.
| Question | Managed screenshot API | Self-hosted Playwright or Puppeteer |
|---|---|---|
| Browser installation and updates | Handled by the API service | Owned by your team |
| Capture call | HTTPS request with JSON settings | Browser automation code in your runtime |
| Low-level browser control | Limited to documented options | Full control over browser behavior |
| Scaling concurrent workers | Service concern | Infrastructure and queueing concern |
| Best fit | Repeatable captures with a defined request model | Highly custom browser sessions and application tests |
A managed API fits repeatable captures where you do not need every browser interaction. A self-hosted browser fits deeply customized end-to-end tests. Choose the boundary that leaves your team owning the code that differentiates the product.
The x-snapshotsiteapi-key header authenticates the request. Never embed that value in public browser JavaScript, a mobile binary, a public repository, or a client-visible error message. Read it from a server-side environment variable and proxy only the data your client is allowed to receive.
If users can submit target URLs, validate the input before it enters your workflow. Consider an allowlist when the product is designed to capture only known domains. Avoid logging URLs that contain credentials, access tokens, or sensitive query parameters.
Store the capture settings next to the job definition: URL, width, height, fullSize, format, delay, and cleanup options. Reusing the same settings makes failures reproducible and comparisons meaningful.
For regression work, use a fixed viewport, remove only known transient UI, and prefer a deliberate wait over an arbitrary large delay.
Check the HTTP status before parsing the response. Log a job identifier and sanitized target URL, but not the API key. Retry transient failures deliberately; repeated requests cannot fix an invalid URL or permanent access problem.
Do not generate the same screenshot on every request to your own application. Cache or store an appropriate result and refresh it when the underlying page or capture requirements change. This reduces latency, API usage, and duplicate work.
fullSize: true when only a small thumbnail is needed.For a typed integration, use the TypeScript SDK, Python SDK, or PHP SDK. For raw HTTP details and endpoint-specific fields, the Snapshot Site API documentation remains the source of truth.
A website screenshot API is an HTTP service that opens a URL in a browser, renders the page, and returns a screenshot or document output. It lets an application capture websites without running and maintaining its own browser workers.
Yes. Set fullSize to true to capture the scrollable page rather than only the configured viewport. Use a viewport capture when you need a fixed fold or device-sized result.
The page is rendered in a real browser. Add a short delay when content appears after initial load, and use the documented v2 or v3 rendering controls when you need DOM waiting or more advanced page preparation.
The documented screenshot endpoints support PNG, JPEG, WebP, and PDF outputs. Choose PNG for lossless images, JPEG or WebP for lighter assets, and PDF when the result should behave like a document.
Use hideCookie for common cookie banners. Supported endpoints also provide a hide option for comma-separated CSS selectors when you need to remove known page elements before capture.
No. Send requests from your server, serverless function, or trusted automation environment so the API key is not exposed to visitors. Return only the screenshot data your client needs.
Yes. For direct before-and-after comparison, use Snapshot Site's Visual Diff API. It returns normalized captures, a diff image, and mismatch information for review workflows.
Use the online Screenshot Generator to try common capture controls, then follow the API documentation or an official SDK page when you are ready to integrate the workflow.
Start with a real URL, choose the page state and output you need, and move from a manual capture to a repeatable API workflow.