Visual proof
Capture the page state your team can review, share, and archive
Some public web workflows need more than parsed text. A support team may need to prove what a customer saw. A QA team may need a rendered page state. A compliance workflow may need a portable file. A product pipeline may need a visual record next to the machine-readable response.
ScraperFly lets developers capture screenshots and PDFs from the same request model used for HTML, text, Markdown, JSON metadata, rendering, routing, headers, sessions, and downloadable artifacts. Start with the page, choose the visual output, and add heavier controls only when the target proves they improve the captured result.
What is a web page screenshot and PDF API?
A web page screenshot and PDF API fetches a public URL, optionally renders it in a browser, and returns a visual file instead of only returning source markup or cleaned text. The output can be a screenshot that shows the rendered viewport, or a PDF that preserves a document-style representation of the captured page.
This kind of API is useful when the workflow needs evidence of appearance, layout, rendered content, page state, archive quality, or human review. It does not replace every parsing workflow. HTML, text, Markdown, and JSON metadata are usually better when machines need to extract or compare content. Screenshots and PDFs are better when people, audit trails, approvals, or QA processes need a file they can inspect.
Practical takeaway: use screenshot or PDF output when visual evidence changes the decision, and keep text-based formats for workflows that only need machine-readable content.
When should teams choose a screenshot?
Choose a screenshot when the exact rendered page state matters. Screenshots are strong for visual QA, page appearance checks, support evidence, monitoring snapshots, layout review, ads and landing-page validation, consent banner inspection, or confirming that JavaScript-loaded sections actually appeared in the browser. They give teams a quick visual record of what the page looked like at capture time.
A screenshot is not always the most efficient parser input. It is harder to query than HTML, text, Markdown, or JSON metadata. For machine-only extraction, capture structured response data first. For workflows where a human needs to see the result, screenshots add value because they preserve layout, visible modules, missing assets, overlays, and browser-rendered state that plain text may hide.
| Visual need | Screenshot is useful when | Use another format when |
|---|---|---|
| Rendered state | The page changes after JavaScript, lazy loading, or route hydration. | Source HTML already contains every field your parser needs. |
| Layout QA | The team needs to review visual modules, spacing, overlays, or missing assets. | The workflow only compares text fields or metadata values. |
| Support evidence | A file helps explain what was visible at a specific capture moment. | The user-facing proof can be generated from stored structured data. |
| Monitoring sample | Human review is needed for selected pages, anomalies, or escalations. | Every page can be monitored through status, hashes, or extracted fields. |
| Visual audit | Teams need a browser-like record for review, approval, or archive. | The archive only needs cleaned text, Markdown, or source HTML. |
When should teams choose a PDF?
Choose PDF output when the result needs to behave like a document. PDFs are useful for archives, approvals, compliance packets, customer handoff, internal review, invoices or policy pages captured from public sources, and workflows where the artifact may be stored, shared, attached, or reviewed outside the scraping system.
PDF capture is different from screenshot capture. A screenshot shows a visual viewport. A PDF is better when the page needs a portable document-style record. It can be easier to send through review workflows and easier to keep as a file artifact, but it is still heavier than lightweight text or metadata capture. Use it when the document output matters, not as a default parser input.
For a focused document workflow, the web page to PDF API page goes deeper. For screenshot-only use cases, the website screenshot API page is the narrower path. This page is the bridge for teams deciding between both visual outputs.
How does rendering affect screenshot and PDF output?
Rendering matters because screenshots and PDFs are visual outputs. If a public page depends on frontend JavaScript, the visual artifact may need browser execution before capture. Without rendering, the output could show an empty shell, placeholder content, missing product cards, unloaded route state, or a page that does not match what a user would see.
The practical workflow is to compare. Start with the lightest request. If the page is static and the visual output is complete, keep the request simple. If JavaScript builds the useful page state, enable rendering. If late content appears after browser load, use wait timing carefully. If the target response changes by region, header, session, or delivery path, add only the control that changes the captured result.
For browser-specific decisions, use the JavaScript rendering API guide. The core rule is the same: rendering should solve a demonstrated visual gap, not become a default tax on every capture.
How should developers choose between HTML, text, screenshot, and PDF?
The best output is the one your downstream workflow can use immediately. If the application parses fields, HTML or structured JSON context may be more useful than a file. If the content moves into an AI or review pipeline, Markdown or clean text may be cleaner. If the workflow needs proof of appearance, layout, rendered state, or a shareable artifact, screenshot or PDF output becomes the right choice.
Teams often overbuild visual capture because a file feels definitive. But if no person will review the file and no archive process needs it, visual output may add weight without improving the product. ScraperFly helps keep the decision explicit because screenshots, PDFs, HTML, text, Markdown, and JSON context can be tested as request profiles before production code is wired.
| Output | Best suited to | Main advantage | Trade-off |
|---|---|---|---|
| HTML | Selectors, DOM structure, links, tables, metadata | Preserves source structure for parsers | Needs parsing and cleanup. |
| Text | Search, lightweight analysis, simple content intake | Compact and easy to process | Removes most layout and DOM context. |
| Markdown | AI ingestion, RAG, review, readable content workflows | Keeps headings and links in readable form | Not ideal for precise selector-based extraction. |
| JSON metadata | Logging, routing decisions, response diagnostics | Makes request context inspectable | Does not replace target-specific extraction. |
| Screenshot | Visual QA, support evidence, layout proof | Shows what the rendered browser displayed | Heavier and harder to query than text. |
| Archives, approvals, portable records | Creates a shareable document artifact | Larger and less convenient for parsing. |
What can go wrong with visual capture?
A visual file can be technically generated and still be the wrong artifact. The page might redirect to a login screen, load a consent overlay, show a regional variant, return a CAPTCHA, capture before lazy content appears, produce a blank browser state, or include a page width that does not match the expected viewport. These are not just file problems; they are request-profile problems.
ScraperFly gives teams a cleaner recovery path because the same API surface can adjust rendering, waits, headers, sessions, country targeting, premium routing, and output format. The useful question is not “Can we retry harder?” It is “Which piece of evidence shows what to change?” Status, final URL, response size, screenshot state, and rendered output all help the team decide the next request profile without blindly increasing cost.
How can teams keep visual capture cost predictable?
Visual artifacts are heavier than simple content responses, so they should be reserved for workflows where they create real value. Use screenshots for selected QA states, anomaly review, customer evidence, or visual monitoring samples. Use PDFs for archives, approvals, and document-style handoff. Keep large machine-only runs on HTML, text, Markdown, or JSON metadata when those formats answer the question more efficiently.
The best cost-control habit is classification. Separate pages that need source capture, pages that need rendered capture, pages that need visual files, and pages that need stronger delivery. Then apply those profiles consistently. The API Builder is the fastest way to test this before development, and the pricing page helps teams understand how output choice and request controls affect usage.
Practical takeaway: screenshots and PDFs are high-value outputs when they prove something text cannot, but they should stay tied to a clear review, archive, or QA need.
