Screenshots that hold up under FRE 901.
A standard smartphone screenshot is a second-generation reproduction with no hash, no timestamp, and no chain of custody. Opposing counsel objects, the judge sustains, the exhibit is excluded. receipts.you stamps every sealed image with a SHA-256 hash, an ECDSA P-256 signature, and an externally-anchored OpenTimestamps proof — the three properties courts have been asking for since the Sedona Conference flagged the gap.
Workflows lawyers actually run
- 01
A client sends you a hostile DM screenshot.
Before any forensic work begins, seal the image at receipts.you/seal. The cryptographic hash is computed in your browser; the image itself never reaches our servers. You now have a dated, signed, externally-anchored receipt that establishes when this exact file was in your possession — months before the case file opens, before opposing counsel can argue post-hoc fabrication.
- 02
Discovery exchange with chain-of-custody preservation.
Send the file via channels that preserve bytes (e-discovery upload, encrypted email attachment, Signal-as-document). Opposing counsel drops it into /verify, confirms byte-identical match, and the chain of custody from your client to their desk is mathematically tight. No screenshot-of-screenshot reproduction, no metadata loss.
- 03
An exhibit's authenticity is challenged at trial.
Hand the judge the receipt URL. The verification page (server-rendered HTML, browser-friendly, no app install) walks anyone through SHA-256 verification with the published ECDSA public key, plus the independent OpenTimestamps proof confirming the timestamp predates any disputed event. The cryptography is reviewable; the timestamp is anchored to a public blockchain so even receipts.you can't backdate it.
- 04
Source-protection scenario.
A whistleblower screenshots material they're not yet ready to release. Seal now, sit on it. The receipt is a public dated artifact pointing to a 32-byte hash; the source's identity stays with them; the file stays with them. If the story breaks five years later, the date is provable without ever exposing the source.
What it maps to in your world
- FRE 901(a) authentication: SHA-256 byte-identity match is a stronger 'distinctive characteristic' than any metadata claim.
- FRE 902(13) self-authentication of electronic records: the ECDSA P-256 signature is a 'certification by a qualified person'-equivalent embedded in the artifact itself.
- ISO/IEC 27037 (digital evidence identification, collection, acquisition, preservation): receipts.you provides the integrity guarantee component out of the box.
- eIDAS (EU) qualified timestamp model: OpenTimestamps' Bitcoin-anchor proof is independently verifiable forever, satisfying the 'long-term archival' property.
- PIPEDA (Canada) / GDPR (EU): image bytes never reach our servers, only a 32-byte hash does. The privacy posture is verifiable from the published code.
- California Evidence Code §1552 / NY CPLR 4518: dated hash + signed receipt addresses the authentication element directly.
Questions this page answers
- “are screenshots admissible in court”
- “screenshot evidence FRE 901”
- “self-authenticating electronic records FRE 902(13)”
- “chain of custody screenshot”
- “qualified timestamp authentication”
- “ISO/IEC 27037 digital evidence”
- “screenshot text message admissibility”
- “authenticating social media screenshot”
- “screenshot hash forensic”
- “eIDAS qualified timestamp screenshot”
Specific answers
Does this replace a forensic expert?
No. A forensic expert authenticates the device, the operating system path, the chain of custody from device to evidence locker. receipts.you authenticates the file. Both layers are useful; they're not substitutes. The product is the file-level guarantee a forensic expert would otherwise have to build manually.
What if opposing counsel challenges the OpenTimestamps anchor?
Hand them the .ots proof bytes (served at /api/r/<id>/ots, raw binary) plus a link to the OpenTimestamps verifier (open source, runs offline). The anchor proof walks the Merkle path to a confirmed Bitcoin block header. They can verify against blockchain.info, Mempool.space, or any independent block explorer. No trust in receipts.you required.
How do you handle modified screenshots — say, redaction of personal info?
Seal the unredacted original first. Then redact a separate copy, seal that too. The two receipts document the editorial transformation explicitly: "this is what the witness produced; this is what was submitted to discovery." Both timestamps are independently anchored.
Can it identify a screenshot that's been recompressed by a platform?
Yes. Each sealed receipt stores both the SHA-256 hash and a 64-bit perceptual hash. If the file passed through Twitter/WhatsApp/Instagram and the bytes no longer match, /verify still returns a 'recompressed' verdict when both perceptual hash bands are inside threshold (pHash ≤ 6 AND dHash ≤ 9). The verdict ladder is documented on /methodology with the exact bit-distance thresholds.
Is the source code public?
Yes — the entire stack, including the verifier client. The signing key is private (a Wrangler Secret in our Cloudflare account); everything else is auditable. Reading the code is the fastest way to confirm the cryptography matches the marketing.
Pricing for a firm?
Free for the public API today. If you need higher rate limits, batch sealing for case management software, REST API with bearer auth, or an on-premise build for client-confidential work, email [email protected] with the shape of your firm and the case volume.
Carry receipts on the screenshot before the case file opens.
Seal the file today, before opposing counsel asks where it came from. Free, in your browser, image bytes never reach us.