Take a Screenshot of a URL — One API Call
Taking a screenshot of a URL with SnapAPI requires a single HTTP GET request with your API key and the target URL as query parameters. The API renders the page in a real Chromium browser, waits for JavaScript to execute and content to load, and returns the screenshot as binary PNG, JPEG, WEBP, or PDF data in the response body. There is no SDK required, no SDK to install, and no browser binary to manage. Any HTTP client in any programming language can make the request and receive the screenshot bytes.
# The simplest possible screenshot: curl
curl "https://snapapi.pics/screenshot?access_key=YOUR_KEY&url=https://example.com&format=png" -o screenshot.png
# Python
import requests
img = requests.get('https://snapapi.pics/screenshot', params={
'access_key': 'YOUR_KEY', 'url': 'https://example.com', 'format': 'png'
}).content
open('screenshot.png', 'wb').write(img)
// JavaScript (Node 18+)
const res = await fetch('https://snapapi.pics/screenshot?access_key=YOUR_KEY&url=https://example.com&format=png');
const buffer = Buffer.from(await res.arrayBuffer());
require('fs').writeFileSync('screenshot.png', buffer);
Full-Page vs Viewport Screenshot
By default, SnapAPI captures the visible viewport — the above-the-fold area at the configured viewport dimensions. To capture the entire page from top to bottom, including content that requires scrolling, add full_page=1 to the request. Full-page screenshots are ideal for archiving, visual regression testing, and documentation where the entire page content needs to be visible. Viewport screenshots are better for thumbnail generation, link previews, and monitoring dashboards where you want to show what the page looks like at first glance without a long screenshot that requires scrolling to view.
Screenshot Options Reference
| Parameter |
Values |
Default |
| format | png, jpeg, webp, pdf | png |
| full_page | 1 or 0 | 0 |
| viewport_width | 320–2560 pixels | 1280 |
| viewport_height | 240–2048 pixels | 800 |
| delay | 0–10000 ms | 0 |
| wait_for_selector | CSS selector string | empty |
| thumb_width | Pixels (resizes output) | original |
Screenshot of Dynamic and JavaScript-Rendered Pages
SnapAPI renders every URL in a real Chromium browser, so JavaScript-rendered single-page applications, React and Vue SPAs, dynamic dashboards, and AJAX-loaded content are all captured correctly. For pages where content loads asynchronously after the initial render — infinite scroll feeds, lazy-loaded images, charts that render after an API call — use the delay parameter to add a millisecond wait after page load before capturing, or use wait_for_selector to specify a CSS selector that should be visible before the screenshot is taken. For pages behind login, pass session cookies via the cookies parameter. For pages that serve different content based on the User-Agent, pass a custom User-Agent header. All of these parameters work identically in all supported output formats — PNG, JPEG, WEBP, and PDF.
Screenshot Rate Limits and Caching
SnapAPI enforces rate limits at the API level to prevent abuse and ensure service quality for all users. The free tier allows up to 10 requests per minute. Paid plans have higher rate limits specified in the plan documentation at snapapi.pics/pricing.html. Applications that need to generate screenshots faster than the rate limit allows should cache screenshot results and serve cached versions for repeated requests for the same URL. A simple URL-keyed cache with a 1-hour TTL eliminates duplicate API calls for the same URL within the cache window, reducing effective API usage and keeping response times fast for cache hits. For burst use cases — generating 1,000 screenshots in a short window for a batch job — spread the requests over time with a throttled queue rather than sending all requests simultaneously, which would hit the rate limit and require retry handling.
Common Screenshot URL API Use Cases
The screenshot URL API serves a wide range of production applications. Link preview services generate thumbnail images for URLs shared in messaging apps, bookmark managers, and content dashboards — showing a visual preview of the destination page before the user clicks. Social media scheduling tools capture previews of shared URLs to show creators how their posts will appear in social feeds before publishing. Competitor monitoring tools take periodic screenshots of competitor pages to track changes in pricing, messaging, and feature availability over time. Visual regression testing systems capture page screenshots before and after code deployments to detect unintended visual changes. Web archiving systems capture timestamped screenshots for compliance, legal evidence, and historical records. SEO audit tools take screenshots alongside SERP data to show clients what their pages look like in search results. All of these use cases require the same underlying capability: taking a reliable, accurate screenshot of any URL on demand, which is exactly what the SnapAPI screenshot endpoint delivers.
Full Parameter Reference
The SnapAPI screenshot endpoint accepts a comprehensive set of parameters that control every aspect of the capture. The url parameter is required and must be a fully qualified URL including the scheme. The format parameter defaults to png and accepts jpeg and webp for smaller file sizes: webp produces the smallest files at comparable visual quality and is recommended for high-volume thumbnail generation. The full_page parameter is a boolean that defaults to false, capturing only the visible viewport; set it to true to capture the entire page height including content below the fold. The viewport_width and viewport_height parameters control the simulated browser window size in pixels, defaulting to 1280 and 800 respectively; common responsive breakpoints are 375 for mobile, 768 for tablet, and 1440 for wide desktop. The delay parameter accepts a value in milliseconds and waits that duration after the page load event fires before capturing, useful for pages with CSS animations, delayed content loading, or deferred API calls that populate visible content after initial render. The wait_for_selector parameter accepts a CSS selector and waits until that element is present in the DOM before capturing, which is more precise than a fixed delay for pages with predictable dynamic content. The thumb_width parameter rescales the output image to the specified width in pixels while preserving the aspect ratio, enabling server-side thumbnail generation without a separate image processing step. The block_ads parameter removes ad content from screenshots, producing cleaner visual captures for monitoring and archiving use cases. All parameters are passed as standard query string values and are documented with examples at snapapi.pics/docs.
Integrating Screenshot API Into Your Product
Integrating a screenshot API into a production product requires decisions about where to call the API, how to handle latency, and how to manage storage. The most important architectural decision is whether to capture screenshots synchronously (in the request path, returning the image immediately) or asynchronously (in a background job, storing the result and notifying the caller when ready). Synchronous capture works well for on-demand use cases where the user expects to wait a few seconds: a browser extension screenshot button, a developer tool that generates previews, or an admin dashboard that shows live page thumbnails. Asynchronous capture works better for batch operations, scheduled monitoring, and any case where the user should not wait for the screenshot: generate a task ID, enqueue the capture job, return the task ID to the caller, and deliver the completed screenshot via webhook or polling. For storage, S3-compatible object storage is the natural backend: SnapAPI returns the raw image bytes which you write directly to S3 with a PUT request, store the S3 key in your database, and serve images via CloudFront or a signed URL. This pattern avoids serving images from your application server, decouples storage from application logic, and scales to any volume without infrastructure changes. For caching, deduplicate screenshot requests by URL and a reasonable TTL: a one-hour cache for frequently-requested URLs eliminates redundant API calls on popular content, while a 24-hour or weekly cache for monitoring snapshots of stable pages dramatically reduces monthly request consumption. The free tier at 200 requests per month is sufficient to validate this architecture end-to-end before upgrading to a paid plan.
Common Integration Mistakes to Avoid
Several patterns consistently cause problems in production screenshot API integrations. The first is calling the API synchronously from a web server request handler without a timeout: if the target URL is slow or unresponsive, the screenshot request hangs, the web server thread is held, and under load the thread pool exhausts, causing cascading failures. Always set an explicit HTTP client timeout of 30 to 60 seconds on the SnapAPI call and handle the timeout as a graceful failure. The second mistake is not handling the case where the target URL returns a non-200 status or is unreachable. SnapAPI returns an error response body in this case rather than an image; code that blindly saves the response body as an image file will save an error JSON as a PNG, causing confusing downstream failures. Always check the Content-Type header of the response before treating the body as image bytes. The third mistake is generating screenshots of URLs that contain session tokens, authentication parameters, or personal data in the query string. Any URL passed to a screenshot API may be logged in server access logs, error reports, or monitoring dashboards at the API provider. Pass session-authenticated pages through the cookie parameter rather than embedding credentials in the URL. The fourth mistake is not rate-limiting screenshot generation on your side. If your application allows users to trigger screenshot generation, add per-user or per-IP rate limiting to prevent a single user from exhausting your monthly quota. These patterns are straightforward to implement and prevent the most common production incidents in screenshot API integrations.