Certified Screenshot API — SHA-256 Hash & Timestamp Proof

Someone disputes what your website showed on a specific date. Maybe a competitor copied your pricing page. Maybe a regulator wants proof of what terms were live last week. You open your screenshot folder and find... a PNG file with no metadata. No timestamp you can trust. No way to prove the image wasn't edited in Photoshop five minutes ago. A certified screenshot API solves exactly this problem, and below we'll walk through how it works, how to verify the hash, and where it actually matters.

ScreenshotRun's certified parameter adds a SHA-256 hash of the image file, the exact capture timestamp, and a hash of the options you used to every response. That's your proof chain: the image, its fingerprint, and when it was taken.

What the certified screenshot API adds to every response

A regular screenshot request returns the image and some metadata. Width, height, file size, status. Useful, but none of it proves the image is authentic.

With certified=true, the response includes a certification object:

curl "https://api.screenshotrun.com/v1/screenshots/capture?url=https://example.com&certified=true&response_type=json" \
  -H "Authorization: Bearer YOUR_API_KEY"

The JSON response now contains:

{
  "data": {
    "id": "a1b2c3d4-...",
    "status": "completed",
    "url": "https://example.com",
    "file_size": 284710,
    "width": 1920,
    "height": 1080
    // ... other fields omitted for brevity
  },
  "certification": {
    "sha256": "e3b0c44298fc1c149afbf4c8996fb924...",
    "captured_at": "2026-10-09T14:32:18+00:00",
    "url": "https://example.com",
    "options_hash": "9f86d081884c7d659a2feaa0c55ad015...",
    "file_size": 284710,
    "screenshot_id": "a1b2c3d4-..."
  }
}

Every field in that certification object serves a purpose. The sha256 is the fingerprint of the actual image file. Download the screenshot, run sha256sum on it, and you'll get the same 64-character string. If even one pixel was altered after capture, the hash won't match. That's how SHA-256 works: change one byte, the entire hash changes.

The options_hash locks down the capture settings. It proves the screenshot was taken at 1920x1080 on desktop with specific parameters, not secretly re-captured at different settings later.

Screenshot hash verification in practice

Hashing sounds abstract until you actually use it. The workflow is simple: you capture a certified screenshot of your competitor's website, save the image file, and store the certification data separately (a database, a JSON file, whatever works). Three months later, someone questions whether the screenshot is real.

You verify it:

# On Mac or Linux — verify the screenshot hasn't been altered
sha256sum competitor-pricing-2026-10-09.png
# Output: e3b0c44298fc1c149afbf4c8996fb924...

# Compare with the stored certification hash
# If they match — the file is exactly what the API captured

That's it. No third-party verification service needed. Anyone with the image file and the original hash can confirm the screenshot is untouched. SHA-256 hasn't been broken. There's something satisfying about seeing a matching hash after months of wondering "did someone edit this file?"

For a more complete setup, here's a Python script that captures and verifies in one go:

# Python — capture and verify in one script
import hashlib
import requests

result = requests.get(
    "https://api.screenshotrun.com/v1/screenshots/capture",
    params={
        "url": "https://example.com/pricing",
        "certified": "true",
        "response_type": "json"
    },
    headers={"Authorization": "Bearer YOUR_API_KEY"}
)

data = result.json()
cert = data["certification"]

# Download the image and verify
img = requests.get(data["data"]["links"]["image"],
                   headers={"Authorization": "Bearer YOUR_API_KEY"})
local_hash = hashlib.sha256(img.content).hexdigest()

assert local_hash == cert["sha256"], "Hash mismatch — file was modified"
print(f"Verified: captured at {cert['captured_at']}")

Three response formats, three places for certification data

Where the certification data shows up depends on how you receive the screenshot.

With response_type=json, the certification object sits right in the JSON body, next to the regular screenshot data. Easiest format to work with. If you also need the image as a base64 string, use response_type=base64 and the certification object appears alongside the encoded image data, ready for embedding into HTML or emails.

Binary image responses (the default, no response_type) are different. You can't put JSON inside an image file, so the certification data arrives as HTTP headers instead:

X-Certification-SHA256: e3b0c44298fc1c149afbf4c8996fb924...
X-Certification-Timestamp: 2026-10-09T14:32:18+00:00
X-Certification-URL: https://example.com
X-Certification-Options-Hash: 9f86d081884c7d659a2feaa0c55ad015...
X-Certification-Screenshot-ID: a1b2c3d4-...

If you're using the binary response, make sure your code reads and stores these headers. The image file alone won't carry the certification data with it. File size isn't included as a header because you can read it from Content-Length.

One detail worth knowing: if you use cache_ttl together with certified=true and a cached screenshot is returned, the certification data reflects the original capture time, not the time you requested it.

Where certified screenshots actually matter

Most screenshot use cases don't need certification. Thumbnails for a dashboard? Social media previews? Visual regression tests? Regular screenshots work fine. Certification adds value when someone might question the authenticity of what you captured.

A company copies your website design. You need proof of what their site looked like on a specific date. A certified screenshot with a SHA-256 hash and ISO 8601 timestamp is stronger evidence than "I have a PNG file somewhere." Your lawyer can explain the hash to a judge, and opposing counsel can independently verify it. That's the legal evidence angle.

Financial services, healthcare, and government agencies have a different problem. They need to archive what their public-facing websites displayed, and regulations like MiFID II and SEC Rule 17a-4 require proof that records haven't been altered. A certification hash covers that compliance requirement without buying a dedicated archiving platform.

Brand protection works the same way. Counterfeit products on marketplace sites, unauthorized use of your trademarks, competitors scraping your prices to undercut you. Certified screenshots create a timestamped, verifiable record of infringement that holds up when you file a takedown notice. And when a client claims your SaaS pricing was different when they signed up (happens more often than you'd think, sometimes 3-4 times a year on active products), a certified screenshot archive settles the argument fast.

Certified screenshots vs. dedicated evidence services

Dedicated web evidence services like TrueScreen and SaveTheProof exist specifically for legal-grade website certification. They typically charge $2.50 to $7 per capture and add features like RFC 3161 timestamps (a standard where a trusted third party cryptographically signs the timestamp) and sometimes blockchain anchoring.

ScreenshotRun's certified screenshot API is simpler. You get a SHA-256 hash and an ISO 8601 timestamp generated by our servers. No RFC 3161 timestamp authority, no blockchain receipt. For many use cases (compliance archiving, brand monitoring, internal records), that's enough. The hash proves the file wasn't changed, and the timestamp comes from a verifiable server.

For court proceedings where the opposing counsel might challenge the timestamp source itself, a dedicated service with third-party timestamping is worth the extra cost. For everything else, certified=true gives you tamper-proof screenshot verification at no extra charge.

What certified screenshots don't prove

Honesty matters here. The certified parameter proves two things: the image file hasn't been modified since capture, and when the capture happened. It does not prove:

• That the website actually displayed that content to real users (the API sees the page through a headless browser, which some sites serve differently)
• That no one tampered with the page before capturing it (if you inject custom CSS or JS, the screenshot reflects your modifications)
• That the timestamp is legally binding (it comes from our server clock, not a trusted timestamp authority)

For most business use cases, these caveats don't matter. You're capturing public URLs without modification, and the hash chain is strong enough to settle disputes internally. But if you need evidence that will survive cross-examination in court, talk to a lawyer about whether API-generated timestamps meet the evidentiary standards in your jurisdiction. We don't have a clean answer for every legal system.

Certified screenshot API reference

Certification response fields

Binary response headers

When using the default binary response (no response_type parameter), certification data is returned as HTTP headers: X-Certification-SHA256, X-Certification-Timestamp, X-Certification-URL, X-Certification-Options-Hash, X-Certification-Screenshot-ID.

Certified screenshots pair well with other API features. Use full page mode to capture an entire scrollable page with its certification hash. Combine with PDF export for archival-quality documents that include the hash in the response metadata. Or add webhook delivery to get certified screenshots pushed to your server automatically when they're ready.

The short version

Add certified=true to any screenshot request. You get back a SHA-256 hash of the image, an ISO 8601 timestamp, and a fingerprint of the capture settings. Download the file, run sha256sum, compare the output. If the hashes match, the screenshot is exactly what the API captured — not a single pixel changed. No extra cost, no third-party service, no setup. One boolean parameter turns every screenshot into a verifiable record.