PDF ARTIFACTS
Capture the page as a PDF when the result needs to be reviewed, shared, or archived
ScraperFly gives teams an API-first way to turn a public URL into a PDF artifact. That is useful when the output is not just data for a parser, but a durable record for approvals, compliance checks, customer handoff, support evidence, internal QA, or page archives.
The request can stay practical. Test the target, render JavaScript only when the page needs it, wait for late content only when samples prove timing matters, and keep HTML, text, Markdown, JSON metadata, or screenshots available when PDF is not the right output.
What is a web page to PDF API?
A web page to PDF API accepts a public URL and returns a PDF representation of the captured page. Instead of running a browser farm, building a PDF renderer, managing proxy delivery, and stitching file handling into the backend, the application can request a document-style artifact from a hosted API workflow.
PDF capture is different from normal scraping output. HTML, text, Markdown, and JSON are machine-friendly formats. PDF is a review-friendly format. It is valuable when a human, customer, auditor, support team, or downstream process needs a portable record of what the public page looked like after the request completed.
That distinction keeps the page honest. A PDF should not replace structured parsing when the product needs fields, links, prices, headings, or metadata. It should be used when a file artifact makes the workflow easier to approve, archive, share, or inspect.
Practical takeaway: use PDF output when the next step needs a document record, not just extracted page data.
When is PDF better than a screenshot?
Screenshots are fast visual proof of a browser state. PDFs are better when the captured page needs to behave like a document. A PDF can be attached to a ticket, stored in an archive, reviewed by a non-technical team, passed to a customer, or used as a durable record for approval and compliance workflows.
For layout QA, a screenshot may be enough. For a customer-facing report, invoice-like page, policy page, search result proof, listing evidence, or audit packet, PDF often fits the human workflow better. It gives the team a file that travels well across systems that already understand documents.
| Need | Use PDF when | Use screenshot when |
|---|---|---|
| Review | The page should be shared as a document or attached to a workflow. | The team only needs a quick visual state. |
| Archive | The output should become a portable record that can be stored and retrieved later. | A thumbnail or layout snapshot is enough. |
| Compliance | The capture needs a document-style artifact for audit or approval. | The proof is mainly visual QA. |
| Customer handoff | A non-technical recipient expects a PDF-like file. | The file is only used internally for debugging. |
| Automation | The application routes documents between systems. | The application compares pixels or visual states. |
For workflows that need both visual formats, the broader web page screenshot and PDF API page explains how to choose between them. This page stays focused on PDF as the primary deliverable.
How does rendering affect PDF capture?
A PDF generated from the wrong page state is still a bad artifact. Many public pages send complete useful content in the first HTML response. Others build the important content after JavaScript runs, change content by region, show overlays, lazy-load sections, or redirect based on request context.
ScraperFly can use browser rendering before PDF output when the useful public page state depends on JavaScript. Wait timing can help when lazy sections need a moment to settle. Headers, cookies, sessions, country targeting, and stronger routing can help when the target returns different content for different visitors.
The goal is not to make every PDF request heavy. The goal is to prove which capture profile creates the right artifact for a target pattern. Compare source response, rendered response, screenshot state, final URL, status, and file output before applying the same settings to a batch.
Practical takeaway: render PDF captures when JavaScript changes the document you need to preserve.
What should teams validate before trusting PDF output?
PDF output is useful because it is easy to share, but that also makes mistakes more visible. A wrong redirect, consent screen, blank page, login wall, CAPTCHA state, or slow-loading section can create a file that looks valid while preserving the wrong content.
- Final URL and status. Confirm the PDF came from the expected public page, not a redirect, placeholder, or soft error.
- Rendered state. Check whether JavaScript execution changes the page before capture.
- Wait timing. Give lazy content and route transitions enough time only when real samples prove the need.
- Viewport and page shape. Make sure the captured layout fits the document-style record your workflow expects.
- Overlays and banners. Consent prompts, modals, and interstitials can dominate a PDF if the request context is incomplete.
- Content versus proof. Keep machine-readable formats available when the application needs data, not a document artifact.
These checks help separate a PDF problem from a delivery problem. If the target returns the wrong page state, the fix may be rendering, headers, sessions, country targeting, wait timing, or routing. If the product needs structured fields, the fix may be a different response format.
How is web page to PDF different from HTML scraping or Markdown output?
HTML scraping is usually the starting point when the product needs parseable markup, selectors, attributes, links, tables, or exact DOM relationships. Web page to Markdown is useful when content should move into AI, RAG, documentation, search, or review workflows in a readable shape. PDF is useful when the output should be a file.
That makes PDF a delivery format, not the universal best scraping format. If your application wants to calculate prices, extract product fields, compare headings, index text, or build a dataset, PDF is usually less convenient than HTML, text, Markdown, or JSON metadata. If your application wants to attach a public page capture to an approval flow, archive a record, or give a human a portable view, PDF makes sense.
| Output | Best fit | Trade-off |
|---|---|---|
| Review, archive, approvals, compliance packets, customer handoff. | Less convenient for parsing and usually heavier than text output. | |
| Screenshot | Visual QA, browser-state proof, layout checks, selected monitoring samples. | Great visual evidence, but hard to query as data. |
| HTML | DOM parsing, selectors, links, attributes, tables, exact source evidence. | Requires cleanup and parser logic. |
| Markdown | AI, RAG, docs, review, and readable content workflows. | May simplify complex DOM structures. |
| JSON metadata | Request diagnostics, final URL, status, content type, logging. | Does not replace target-specific extraction. |
Use the API Builder to compare those outputs on the same target URL before committing a production workflow. A small amount of testing prevents a team from building document workflows around pages that only needed lighter response formats.
Practical takeaway: choose PDF when the artifact itself is valuable; choose lighter formats when the consumer needs data.
How can ScraperFly keep PDF capture practical?
ScraperFly is useful because PDF capture stays inside the same request model as the rest of the web scraping workflow. The team can test the target URL, inspect response evidence, compare formats, enable rendering when JavaScript matters, add wait timing when page state is late, and use routing controls when delivery changes the result.
That keeps the buying decision cleaner too. A one-off review job can use pay-as-you-go credits. A recurring archive or QA process can move toward monthly credits once the target behavior and request weight are proven. Review pricing after the capture profile is clear, not before the team knows whether PDF output is actually needed.
If the workflow needs a file returned from the API, connect this page with downloadable artifacts. If the workflow needs visual proof but not a document, compare with the website screenshot API. The best PDF workflow is specific enough to preserve the right page and disciplined enough not to turn every scrape into a document job.
