Snapshot Site can produce PNG, JPEG, WebP, PDF, and rendered HTML through its documented screenshot workflow. Format choice affects fidelity, compatibility, downstream processing, storage, and review—not page readiness.
format: png | jpeg | webp | pdf | htmlSNAPSHOT_SITE_API_KEY
All formats depend on reaching the correct page state. Viewport, full-page behavior, timing, and cleanup should not become implicit merely because the output changes.
Lossless raster output for sharp interface evidence and controlled visual baselines.
Lossy raster output for photographic previews where exact pixels are not required.
Modern raster output when the entire storage and consumer path supports it.
Document or rendered-DOM artifacts for workflows that need more than an image.
Name the consumer and evidence requirement
Choose the format supported by its complete processing path
Send an explicit screenshot request and check status
Validate the artifact before storing or presenting it
Change the format only after the viewport and intended page state are defined.
{
"url": "https://example.com/report",
"format": "png",
"width": 1440,
"height": 900,
"fullSize": true,
"hideCookie": true,
"delay": 1
}
A screenshot service may feed a review UI, archive, document system, diff engine, CMS, or parser. Each consumer has different expectations. Record the chosen format in the job specification and explain why it is suitable.
Avoid converting between formats repeatedly without preserving the original artifact and provenance. Each conversion can change pixels, metadata, or document behavior.
PNG keeps raster data lossless and suits sharp UI evidence. JPEG is lossy and can suit photographic previews. WebP is a modern web-oriented format that requires compatibility through the entire processing chain. None of these choices defines when the page is ready.
Test small text, gradients, photography, transparency expectations, and final display size on representative routes.
PDF is appropriate when the consumer needs a document rather than an image. Validate page breaks, print styles, fonts, and downstream document handling. Rendered HTML is data: parse it safely and preserve the context that produced it.
A returned link or structured response is not complete success until the application validates expected fields and imports the artifact when stable ownership is required.
Use the individual PNG, JPEG, WebP, and HTML guides for format-specific implementation decisions.
The documented screenshot workflow supports PNG, JPEG, WebP, PDF, and rendered HTML output.
A controlled lossless PNG is a practical baseline when exact pixel evidence matters. Keep every capture setting identical.
Use it for visually rich previews where lossy compression is acceptable and small interface details are not the primary evidence.
Use it when the full storage, processing, review, and delivery path supports WebP and the result fits the visual requirement.
No. Treat PDF as a document output with its own consumer and validation needs. Test page layout and print-related behavior.
It supports authorized parsing, DOM analysis, and debugging after client JavaScript has built the page.
No. The requested page must still reach the intended state before any output is meaningful.
Check HTTP status, expected structured fields, artifact availability, format expectations, and storage outcome before marking the job ready.
Name the consumer, choose the artifact intentionally, and validate it with representative pages before standardizing.