Archiving a web page as it looked on a date

Capture a page as PDF or PNG with the upstream status, content type and render time recorded alongside it, so an archive carries the conditions it was taken under.

Regulated teams, legal teams and anyone handling disputes need to show what a page said on a given day. A screenshot on its own is weak evidence. A screenshot plus the conditions it was captured under is much stronger.

curl -D headers.txt -o archive/2026-10-21-terms.pdf \
  "https://api.screenshotline.com/take?url=https://example.com/terms&format=pdf&full_page=true&cache=false" \
  -H "X-Access-Key: $KEY"

Keep headers.txt next to the file. It records what the renderer saw:

  • X-Upstream-Status, the status the target returned, so a 404 archived by mistake is obvious later.
  • X-Upstream-Content-Type, which separates a page from a redirect to a file.
  • X-Render-Ms, how long it took.
  • X-Blank-Suspected, so an empty capture is marked rather than filed.
  • X-Text-Length, a rough measure of how much text was present.

PDF or PNG

PDF keeps text selectable and is the usual choice for an archive. PNG records the exact pixels, which matters when the question is how the page rendered rather than what it said. Capturing both costs two renders and ends the argument.

Decide these before you start

Cache off. An archive of a cached render is an archive of an earlier moment.

Record the request as well as the response: the URL you asked for, the time you asked, and the options you used. The API cannot know what you meant to capture.

Decide what a bot wall means to you. If the site serves a challenge, you have archived the challenge. Empty walls are flagged in X-Blank-Suspected, and a captcha comes back as a captcha, which is why the picture is not always the page.

Keep the originals somewhere immutable. Object storage with versioning and a retention policy does more for an audit than any capture setting.

Get a free key — 500 renders a month Read the docs