How to prove a deleted tweet existed

Step 1: Capture

The first move is the basic screenshot. On mobile, power+volume down. On desktop, full-window capture (include the URL bar — it makes downstream verifiers' lives easier). Two practical notes:

• Don't crop yet. Receipts and downstream verifiers hash pixel bytes; a wider capture with more context (URL bar visible, surrounding tweets shown, timestamps from the platform UI) is harder to dispute than a tight crop of just the offending text.
• Don't annotate yet either. Annotations change the bytes. If you want to ship an annotated version later, do that as a derivative; seal the clean original first.

Step 2: Archive (the URL, if you can)

Drop the URL into archive.today and the Wayback Machine. Both will fetch the URL with a server-side crawler and store a copy of the rendered page. Two crawlers, two records, two independent chains of custody if the post is later deleted.

Honest limits: the crawlers don't always succeed. Twitter/X has been rate-limiting archival crawlers off and on for years. Some accounts mark their pages no-archive (the crawler honors the header). Mobile-app-only content (some Snapchat formats, most Telegram channels) doesn't have a URL the crawler can visit. When the archive step fails, capture + seal is the remaining workflow.

Step 3: Seal

Open receipts.you/seal in any browser and drop your screenshot. Your browser computes a SHA-256 hash of the file bytes plus two perceptual hashes (pHash + dHash) for recompression-resilient verification. Only the hashes — about 80 bytes total — get posted to our worker. The image bytes never leave your device.

Our worker signs the hash with ECDSA P-256, mints a receipt record, returns the original image stamped with a QR receipt code, and within thirty minutes our OpenTimestamps cron anchors your receipt to a public blockchain. From that anchor point forward, even we can't backdate your timestamp.

Why all this when you already have a screenshot and an archive.today URL?

• The receipt is portable. The receipt URL works on any device, in any browser, without an archive.today account or a Twitter account. Useful when the matter goes formal.
• The signature is independent of us. The OpenTimestamps anchor lets anyone verify the timestamp without trusting receipts.you — even years after we're gone, if we ever are.
• The perceptual hash survives recompression. When the tweet screenshot travels through WhatsApp, Discord, or a journalist's CMS, the bytes change but the picture doesn't. The verdict ladder returns recompressed rather than failing outright.

Step 4: Verify (and re-verify)

Test the verification yourself: drop your file on /verify. Should return identical for the exact bytes you sealed, recompressed if you re-saved it through a platform, similar if you cropped or annotated, and mismatch for any genuinely different image.

Then verify again from a different device, a different browser, a different network. The receipt is independent infrastructure; it should work everywhere. If it doesn't, that's a bug in us and we want to know.

What this stack proves (and what it doesn't)

The four layers together prove:

• Archive.today/Wayback proves the URL rendered as this content at the crawler's visit time.
• The receipt proves your screenshot file existed in this exact form at the seal time.
• The OpenTimestamps anchor proves the seal timestamp is not retroactive, even by us.
• The perceptual hash proves your file is the same picture even when it later travels through messaging platforms that recompress.

It doesn't prove:

• That the tweet was real. Anyone can mock up a tweet in DevTools and screenshot the mock. The archive layer (if it succeeded) is the strongest evidence that the live URL actually rendered the content.
• Who took the screenshot. Receipts are anonymous; you'd need other corroboration to bind the screenshot to you.
• That the tweet was the user's authentic post. Account compromises happen. The platform's server-side records are the better source for sender authentication.

Edge cases

I screenshotted three weeks ago and only just thought to seal.

The receipt timestamp will be your seal time, not your screenshot time. The receipt proves the file existed in this form by the seal timestamp. If you need older-than-seal evidence, the archive layer (if you also remembered to archive at the time) or the platform's own logs are stronger; the receipt corroborates rather than replaces those.

The tweet is from a verified account that's now suspended.

Suspended-account tweets often disappear from archive.today and Wayback too, because the source returns 404 and the crawler eventually purges. Your sealed copy is independent. The chain becomes: your screenshot (sealed) + any archive snapshots taken before suspension + your own (or witnesses') testimony that you saw the live post.

The user is now denying they posted it.

This is the case the workflow is designed for. The receipt proves the file existed. The archive proves the URL rendered the content. The user's denial is now a credibility question — evidence vs. assertion — rather than evidence vs. evidence.

Speed matters most for short-lived posts

For tweets that get deleted within an hour, the time between seeing the post and sealing your screenshot is the part that matters. We've heard from journalists who run receipts.you on a second tab open at all times during election cycles — the seal takes ten seconds and removes a class of doubt from every screenshot they file.

For the full workflow page with deeper edge cases, see /scenario/deleted-tweet. For journalist-specific workflow notes, see /for/journalists.