Website Screenshot API Playground: Test Requests and Preview Results

A website screenshot API playground lets you build a capture request in a browser, run it, and preview the result before adding the request to your application. Start with a public page URL, viewport, output format, and capture timing. Then check whether the API returned image bytes, a redirect, or JSON; a visible preview alone does not tell you what your integration must handle.

Playground controls differ by provider. For example, ScreenshotAPI.net’s playground documents request controls and generated code, while SnapshotFlow describes live results and generated snippets. Treat provider-specific features as specific to that service, and verify every setting against its API documentation before integrating.

What to check in a screenshot API playground

A playground combines a request builder with an output area. It can help answer two separate questions: “Did these settings produce the image I wanted?” and “What response will my code receive?” Confirm both before you rely on it.

Check	What to verify
Input	Does it accept a public URL, HTML, or both? Do not assume an HTML-input feature is available everywhere.
Viewport	Can you choose a device preset or explicit width and height? Test desktop and mobile separately for responsive pages.
Capture extent	Does it capture the visible viewport or the full scrollable page? Are scroll-triggered effects handled?
Wait behavior	Can you wait for a selector, a fixed delay, network idle, or a scrolling capture? Which behavior is actually supported?
Output	Does the endpoint return image bytes, redirect to a file, or return JSON with a URL and metadata?
Request parity	Can you copy a request, and do the same parameters work with the documented endpoint and HTTP method?

Playgrounds from SnapshotFlow, Screenshotly, and ScreenshotAPI.net describe different combinations of live previews, device or format controls, and generated requests. These are vendor descriptions, not a standard feature set shared by all screenshot APIs. See their playground and playground pages for their own documented controls.

Test a request and preview the result

Choose a public test URL. Use a page you are allowed to capture. Avoid starting with a URL that requires a login, private cookies, or a network location the capture service cannot reach.
Set the viewport. Enter a device preset or explicit width and height. Repeat the capture at the important breakpoints instead of assuming one desktop preview represents mobile behavior.
Choose viewport or full-page capture. Use viewport capture for the visible fold. Use full-page capture when you need the scrollable document. If content appears only after scrolling, check whether the service supports scrolling capture or needs a wait rule.
Select a format. Choose the format your next step can consume. PNG, JPEG, WebP, and PDF are common API output choices, but each playground may expose only some of them.
Set rendering waits deliberately. If a chart or image appears late, wait for a meaningful selector or use a supported delay or network-idle option. An arbitrary long delay adds latency and may still fail to catch content that depends on a particular event.
Run the capture and inspect the image. Check clipping, missing lazy-loaded images, responsive layout, overlays, and whether the requested full page is actually present.
Inspect the HTTP response contract. Check status, content type, headers, and body. Determine whether you received raw bytes, a redirect, or JSON metadata containing a screenshot URL. Do not save an error response as though it were an image.
Copy and verify the request. Treat generated code as a starting point. Compare its URL, authentication method, HTTP method, and parameter names with the provider’s official documentation.

For one documented example of output modes and request behavior, consult the Screenshot API documentation. That API documents JSON behavior for GET by default, a redirect option, and JSON parameters for POST. Those details apply to that API; other services can use different contracts.

Carry the request into code

Use the playground’s generated request when available, then preserve the exact settings that produced the desired preview. The snippets below show the general shape of a request using ScreenshotNeo. Replace the example target URL with the page you are authorized to capture, and store your API key outside source control. See the ScreenshotNeo API documentation for supported parameters and response details.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests

response = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
response.raise_for_status()
with open("shot.webp", "wb") as image_file:
    image_file.write(response.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status} ${res.statusText}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

The cURL form writes the response to a file. The Python and Node.js examples check HTTP success before saving bytes, so an HTTP error page is not silently stored with an image extension. If a provider returns JSON or redirects instead, follow that provider’s documented response contract rather than assuming the body is an image.

Options that affect the preview

Use the following as a request review checklist. The names, availability, defaults, allowed values, and HTTP method vary by provider. Some APIs reserve advanced parameters for POST requests, so check the endpoint documentation rather than adding every option to a GET URL.

Option	When it matters	What to verify
URL or HTML input	You need a live page or a controlled markup sample.	Which input types and URL schemes are accepted; whether HTML input is supported.
Viewport width and height, device preset	You are checking responsive design or matching a target device.	Preset dimensions and whether explicit dimensions override a preset.
Format and quality	You need a raster image or document for a downstream tool.	Supported output types and any quality setting for lossy formats.
Full-page or scrolling capture	You need content below the initial viewport.	Whether the service expands the page, scrolls to trigger content, or imposes page-size limits.
Wait selector, delay, network idle	The target renders asynchronously.	Timeout semantics, selector matching behavior, and whether the requested wait mode is supported.
Element selector	You need a component rather than the whole page.	Selector syntax, missing-element behavior, and whether the element must be visible.
Custom CSS or JavaScript; hidden selectors	You need to alter the rendered page for capture.	Whether injection is supported, when it runs, and which request method accepts it.
Cookies, headers, user agent, authentication	The page varies by session, locale, or request identity.	Credential handling and whether sensitive values are sent in headers or query parameters.
Geolocation, timezone, locale	The rendered page depends on regional settings.	Which emulation fields are available and their expected formats.
PDF options	You need a document rather than a screenshot image.	Paper size, margins, orientation, and page ranges if offered.
Cache and timeout	You need repeatable captures or bounded request time.	Cache-key behavior, TTL controls, and timeout limits.

The Screenshot API documentation lists examples of advanced controls such as custom CSS or JavaScript, hidden selectors, geolocation, timezone and locale emulation, PDF options, cache behavior, and timeout; it also identifies some as POST-only. Check that API’s current reference, and the equivalent reference for any other provider, for exact parameter support.

Understand the response before integration

A preview is a visual result, while an API response is a protocol contract. At minimum, inspect the HTTP status and Content-Type, and determine whether redirects are followed by your client. If the response is JSON, parse it and retrieve the documented image URL if needed. If it is raw image data, save or stream the bytes. If the endpoint redirects, make sure your client follows redirects or handles the destination explicitly.

Do not infer successful capture from a 200 status alone unless the provider documents that behavior. Check documented error fields and headers. Screenshot API documentation may distinguish invalid credentials, malformed input, quota exhaustion, rendering failure, or a missing selector; the exact status codes and response bodies are provider-specific.

Common problems and fixes

Symptom	Likely cause	Fix
Preview is blank or mostly empty	The page did not load, requires browser interaction or authentication, or the capture happened before rendering completed.	Open the URL publicly, check the provider’s error response, and use a supported selector wait or delay. Supply documented cookies or headers only when appropriate.
Images or sections are missing	Lazy loading or scroll-triggered content did not run before capture.	Try full-page or scrolling capture if supported, and wait for the relevant element rather than increasing delay without a target.
Mobile preview looks like desktop	The viewport was not set as expected, a preset was overridden, or the page uses different responsive breakpoints.	Inspect the generated request and verify its effective width and height; test explicit mobile dimensions.
Request returns JSON where an image was expected	The API’s default response is JSON or the request did not select its image/redirect mode.	Read the endpoint docs, request the documented output mode, or parse the JSON and fetch its image URL.
Image file contains an error page	The client saved an HTTP error body without checking status or content type.	Check status and response headers before writing bytes; log a bounded error body for diagnosis.
Authentication or quota error	The key is missing, invalid, exposed incorrectly, or the account has reached a provider limit.	Verify the key and account usage in the provider’s official dashboard or docs. Keep keys out of browser code and public repositories.
Selector capture fails	The selector does not match, the element is added late, or the provider reports absent elements as an error.	Confirm selector spelling on the rendered page and use a supported wait-for-selector option.
GET request rejects an advanced option	The service only accepts that option with POST or under a different parameter name.	Use the documented method and content type; do not assume playground controls map to GET parameters.
Preview differs from the application capture	The playground and production request differ in viewport, cookies, headers, timing, or format.	Compare the full request and environment settings, then replay the same parameters in a local script.

Performance, reliability, and cost

Capture latency depends on the target site’s response and rendering behavior, the requested page extent, and any waits. Full-page capture, large viewports, delayed widgets, and long fixed waits can increase work. Choose the smallest viewport and wait condition that meet the use case, and avoid repeating captures during development when a cached or saved result is sufficient and the provider supports it.

For reliable integration, define a client timeout, handle non-success responses, and distinguish capture failures from successful image bytes. Use bounded retries only for errors that may recover; repeating an invalid URL, missing selector, or bad credential will not fix it. For batch workflows, record the input URL and request settings alongside the result so a failed or unexpected capture can be reproduced.

Playground availability, account requirements, usage limits, and pricing differ by provider and can change. Do not extrapolate one provider’s free quota or price to another. Check the current pricing and usage terms for the service you plan to integrate, and estimate volume from the captures your application will actually request.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. Its clean-capture steps accept cookie and consent banners like a visitor and remove more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the page verdict and billing status in headers. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture.

Here is a runnable cURL request; replace the target URL as needed. See the ScreenshotNeo API docs for options and configuration.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import 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)

Node.js:

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 includes full-page capture with lazy images loaded, element capture, dark mode, device presets and custom viewports, retina scale, PDF settings, HTML-to-image, custom CSS and JavaScript, pre-capture clicks, hidden selectors, wait controls, request blocking, custom headers and cookies, user agent and authorization, timezone and geolocation, transparent backgrounds, resizing, configurable caching, signed image links, async jobs with signed webhooks, bulk capture for up to 100 URLs per call, a usage API, and an OpenAPI spec. Its parameters also accept names used by other screenshot APIs to make migration easier.

Every feature is on every plan: 1,000 screenshots per month free with no card; Starter is $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free. Sign up for 1,000 free screenshots a month with no card.

FAQ

Can I test a screenshot API without writing code?

Yes, if the provider offers a browser playground. A playground can build and run a request, but account and authentication requirements vary.

Does a playground preview prove my production integration will match?

No. It validates one set of inputs in the playground environment. Replay the same URL, viewport, credentials, waits, and output settings through your application to check parity.

Should I use a screenshot API playground or a local browser?

A playground is convenient for checking a hosted API’s request and response. A local browser is useful when you need to inspect your own browser environment or reproduce behavior that depends on local state.

How do I know whether the screenshot API returned an image?

Inspect the status, content type, redirect behavior, and documented response schema. A preview panel can display an image even when the API response your code receives is JSON or a redirect.