receipts.youSeal a screenshot
FAQ · Folio Q
straight answers
§ Sceptical questions

The honest answers.

Q.01

Does receipts.you ever see my image?

No. Your browser computes the SHA-256 hash locally using the Web Crypto API. Only the 32-byte hash is sent to our Cloudflare Worker. The image bytes never leave your device. You can verify this in DevTools → Network — the only thing posted to /api/seal is a JSON object containing the hex digest.

Q.02

Then how can someone else verify my screenshot is real?

You share the stamped image (which has a QR code embedded) and the receipt URL. Anyone scanning the QR lands at the verification page. They drop the image — their browser hashes it locally and sends the hash to /api/verify. Our Worker compares against the two stored hashes (clean original and stamped composite). Match = the image is unaltered since you sealed it. Mismatch = the image has been modified or is a different image entirely.

Q.03

What if someone copies my QR onto a fake image?

Their fake image has a different SHA-256 hash. When they (or someone they want to fool) drops it on the verification page, the hash matches neither original_hash nor stamped_hash → the page returns mismatch. The QR is real but the image attached to it is not. This is the entire point of storing both hashes.

Q.04

Could you fake a receipt yourself?

We sign with our private key, so technically we could mint a receipt for any hash with any timestamp. Two things prevent that: (1) the external timestamp anchor — every hash is independently submitted to OpenTimestamps, so the timestamp in our receipt has to match the anchor transaction that aggregated it. We can't backdate the timestamp network. (2) Reputation — if we ever did this, anyone with the public key and the historical record could prove it, and the product is over.

Q.05

Is this just a notary service? What does it prove?

It proves byte-level provenance since sealing. Specifically: an image with this exact hash existed in our records at the timestamp shown, and any subsequent modification produces a different hash. It does not prove the content depicted is real. Anyone can seal anything, including a fake screenshot. The value is timestamp-evidence: if you seal a real tweet at 10:00 AM and it gets deleted at noon, the receipt is dated proof the image existed in your possession before the deletion.

Q.06

Can I generate fake screenshots and seal them?

Yes, technically. We don't verify content authenticity, only byte-level integrity since sealing. That said, sealing a fabricated screenshot doesn't make it true — the receipt only attests that this image existed in this form at this time. We actively frame the product as an anti-tampering tool, not a truth-machine, and the “what this proves” section appears on every verification page.

Q.07

Do you store the image in any form?

No. The database row contains: receipt ID, two SHA-256 hashes, a timestamp, a signature, an optional note + source URL the user supplied, an OpenTimestamps proof, and country code for abuse rate- limiting. About 400 bytes. There is no image, thumbnail, or any information from which the image could be reconstructed.

Q.08

What if your service shuts down? Does my receipt become useless?

No. Every receipt is anchored into the decentralized timestamp network via OpenTimestamps. Even if receipts.you disappears, anyone with the original image + the OTS proof can verify the hash existed at the anchored timestamp, using the public OpenTimestamps client. The trust ultimately bottoms out at the timestamp network's proof-of-work, not at us.

Q.09

Can I use this for legal proceedings?

Cryptographic timestamps from non-qualified providers (us) are admissible as evidence in most jurisdictions — but the court decides their weight. For formal legal use we recommend pairing a receipts.you seal with a qualified e-timestamping service (eIDAS-qualified providers like DigiCert / GlobalSign in the EU) or with notarisation by a licensed notary. We're a fast, free backbone — not a substitute for professional certification when stakes are high.

Q.10

Why ECDSA P-256, not P-384 or RSA?

P-256 is universally supported by the Web Crypto API in browsers, Workers, and openssl — it works everywhere with zero polyfills. P-384 isn't supported in all browsers; RSA signatures are much larger. P-256 / SHA-256 is the right cryptographic floor for a public-verifier system in 2026.

Q.11

Why Cloudflare-only? Any vendor lock-in concerns?

Cloudflare's free tier covers MVP scale with zero recurring cost: Workers (100k req/day), D1 (5 GB), Pages (unlimited). The signing key is portable — we can export it and re-host on any Worker-compatible runtime (Deno Deploy, Vercel Edge, Bun, etc.) without invalidating any existing receipts. externally anchored receipts remain verifiable even with no provider at all.

Q.12

Will receipts ever break or expire?

No. Receipts are append-only. We never delete or modify them. The signing key is valid for 20 years (and rotation, when it happens, preserves verifiability of all historical receipts by publishing the old public key under its old signer_kid).

Q.13

I'm on the Pro waitlist — what's the launch plan?

Pro launches once Free has real traction and we know which features power users actually request. If you have a specific Pro request now, email hi@receipts.you — early voices weight heavily.

Question that isn't here? Email hi@receipts.you. We answer in writing, link the source.