The honest answers.
where the image goes, what we store, what we don't.
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.
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.
the cryptography, the hashes, the verdict ladder.
Then how can someone else verify the receipt?
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 bytes are identical to what was sealed at the receipt's timestamp. Mismatch = the bytes differ (could be edits, recompression, or a different file entirely — the perceptual-hash verdict ladder distinguishes those cases).
What if Twitter / WhatsApp / a screenshot tool recompressed the image I want to verify?
We also store two perceptual hashes — pHash (DCT-based) and dHash (gradient-based) — at seal time, computed in your browser before the file is forgotten. At verify time, even if the SHA-256 fails because a platform recompressed your file, the perceptual hash gives a verdict: recompressed (same image, just re-encoded by Twitter/WhatsApp), similar (cropped or mildly edited), or mismatch (genuinely a different image). Perceptual hashes are a heuristic, not a cryptographic guarantee — a determined attacker can craft a colliding image — but they survive the recompression that breaks the SHA, which makes the receipt useful through the channels screenshots actually travel through.
I re-saved the stamped PNG and it still verifies — how?
Chrome's libpng encoder is deterministic: re-encoding the same pixels in the same browser session produces byte-identical output, so the SHA-256 matches. Cross-browser this does not hold — Firefox and Safari produce different PNG bytes for the same pixels and the SHA will mismatch. The perceptual hash catches that case and returns recompressed instead of failing. The safest practice: save the stamped image once and share that exact file, rather than re-saving through editors or platforms.
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) Every hash is independently anchored to OpenTimestamps's decentralized timestamp network within minutes; backdating a receipt would require forging that anchor, which we can't do without rewriting a public ledger's history. (2) Reputation — our public key is published; any forgery is provable forever by anyone with the key + the historical record. If we ever did this, the product is over.
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.
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.
what a receipt is and isn't in front of a court.
Is this just a notary service? What does it prove?
It proves byte-level provenance since sealing. Specifically: an image with this exact hash was sealed in our records at the timestamp shown, and any subsequent modification produces a different hash. It does not prove the content depicted is real, who authored the file, or who possessed it. 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 file existed in receipts.you's ledger before the deletion.
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.
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.
the awkward situations real users keep landing in.
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.
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.
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).