When someone sends you a screenshot and you need to know if it's real.
A friend forwards you a screenshot of someone saying something inflammatory. A colleague pastes a screenshot of a Slack message into a discussion. A stranger on the internet says 'look at this leaked DM' and attaches a PNG. Maybe it's real; maybe it's edited; maybe it's fully fabricated. Without provenance, there's no honest answer — even the platform of origin can't always confirm. What you can do: if the screenshot has a receipts.you QR baked in, drop it on /verify and the cryptographic layer tells you whether the bytes match the original seal, are a recompressed copy of the same image, or are a different image altogether (i.e., someone pasted a real QR onto a fake). If there's no QR, the receipt can't help — but you can use the same tooling defensively: ask the sender to seal-and-share if they want their evidence taken seriously.
When this scenario hits you
- A 'leaked DM' screenshot is circulating on social media and you want to know whether to amplify or sit out.
- Your editor sends you a screenshot a source provided and asks 'is there any way to authenticate this?'
- A friend forwards a 'look what they said about you' screenshot and you're not sure if you're being trolled.
- A coworker pastes a screenshot into a Slack thread and you need to know if it's an unedited capture or a montage.
- An ex texts you a screenshot of a third party 'agreeing' to something — you suspect editing.
What you actually do
- 01
Look at the corner of the image — is there a small QR code?
Receipts.you stamps a tiny QR onto the bottom-right of every sealed image. If you see one, the image was sealed at some point by someone with a receipts.you account-less browser session.
- 02
Scan the QR with any phone camera, OR drop the image on /verify.
Both routes hit the same verification page. The page shows the receipt's timestamp, signature, and (if old enough) the OpenTimestamps anchor. The verification step then compares hashes locally — your browser hashes the image, posts the hash, and gets a verdict.
- 03
Read the verdict ladder.
identical means the bytes you have are exactly what was sealed. recompressed means the image is the same picture, just re-encoded by a platform (Twitter, WhatsApp, Discord). similar means the picture has been mildly cropped or edited. mismatch means the bytes don't correspond to anything that was sealed — common when someone pastes a real QR onto a fake screenshot.
- 04
If there's no QR, use the conversation to do due diligence.
Ask the sender for the original file (not a re-screenshot). Ask the source platform's URL. If the screenshot is supposed to be of a public post, find that post directly. If the answer to either is 'I deleted it' or 'it was a private DM,' skepticism is warranted — that's exactly the case where a sealed receipt would have helped.
- 05
If you're the one being asked to vouch for something, suggest sealing it forward.
Tell the original sender 'send me a sealed version, here's how' — receipts.you/seal, no signup, 10 seconds. If they refuse, that's signal.
Why the receipt holds
- The verification page is cryptographic, not heuristic — match or mismatch is binary at the SHA-256 level.
- The QR encodes only the receipt URL, not the image itself; pasting a real QR onto a fake image produces a verdict of mismatch immediately, because the fake's bytes don't match either stored hash.
- Both the clean original AND the QR-stamped composite are hashed when sealing. There's nowhere to hide.
- Verification can happen offline if you have the receipt JSON and our public key — independent of our servers staying up.
Where the receipt stops
- It can't authenticate a screenshot that was never sealed. The cryptography needs a seal to compare against. If the original wasn't sealed, no tooling can retroactively prove its provenance.
- It doesn't prove the content depicted is true. A perfectly real-looking screenshot of a fake tweet, properly sealed, is still a perfectly real screenshot of a fake tweet. The receipt only proves the file existed at the timestamp shown.
- Perceptual hashes are heuristic, not cryptographic — a deliberately crafted collision is theoretically possible, though no one has demonstrated one against AND-gated pHash+dHash in the wild.
Specific questions about this scenario
What does it mean if I see 'similar' or 'recompressed' instead of 'identical'?
recompressed almost always means a platform (WhatsApp, Twitter, Discord, Telegram) re-encoded the JPEG/PNG on its way through their CDN. The picture is the same, the bytes are different. Treat as authentic for storytelling purposes. similar means the image has been visibly altered — cropped, annotated, slightly retouched. Pixels you're looking at are no longer pixel-identical to the original; the original receipt may still be useful context but the verdict is weaker. mismatch means the bytes correspond to neither stored hash — usually a paste-on-fake.
Can I verify a screenshot without uploading it to your server?
Yes. Verification hashes the image in your browser (same path as sealing). Only the 32-byte hash + perceptual hashes are POSTed to our worker. The image itself never leaves your device. You can confirm in DevTools → Network.
What if the QR code in the screenshot is fake / points to a non-existent receipt?
Then /verify returns 'no receipt with that ID' — also a useful signal. A non-resolving QR is itself evidence the screenshot is fabricated, because the QR has to encode a valid receipt URL minted by us. We don't issue QRs without a paired signature and hash row.
I see a screenshot that has NO QR. Is there any way to tell if it's edited?
Not cryptographically. There are heuristic tools (FotoForensics, ELA, EXIF analyzers) that can sometimes spot poor edits, but skilled fakes defeat them all. The honest answer: without a seal at creation time, no after-the-fact tool can prove a screenshot is real. This is exactly the problem receipts.you fixes — but only for screenshots that were sealed.
Can I trust the verifier output, or could someone spoof it?
Verifier output is signed. The /verify endpoint returns the signature alongside the verdict; the page renders our public-key-verified result. You can re-run the verification offline with openssl + our published public key if you want zero-trust assurance.
One drop, one verdict. No upload.
Drop any image on /verify — if it carries a receipts.you QR, you get a cryptographic answer in under a second. Image stays in your browser.