How to tell if a screenshot is real

The reliable answer: cryptographic verification

If the screenshot has a receipts.you QR code in the corner, you have a definitive verdict in under a second. Two routes:

1. Scan the QR with any phone camera. It opens the receipt page; the page asks you to drop the image to verify.
2. Or drop the image directly on receipts.you/verify. Same hash comparison, same verdict, no QR scan needed if the file's already on your machine.

The verdict ladder distinguishes four cases:

• identical — the bytes are exactly what was sealed. The strongest possible match.
• recompressed — the picture is the same; the bytes have been re-encoded by a platform (Twitter, WhatsApp, Discord, Telegram). The original seal is valid; the file you're looking at is a faithful copy of it.
• similar — the picture has been visibly edited: cropped, annotated, mildly retouched. The original seal still exists; what you're looking at is a derivative.
• mismatch — the bytes correspond to neither the original nor the QR-stamped composite. Common case: someone pasted a real QR onto a fake screenshot. The receipt page tells you the QR is real but the attached image is not.

Verification is cryptographic, not heuristic. The match is binary at the SHA-256 level. There's no probability score; the receipt either matches or doesn't.

The unreliable answers: heuristics on raw screenshots

If the screenshot wasn't sealed at capture, no after-the-fact tool gives you a clean answer. Here are the categories of heuristic that exist, and what each is actually worth.

EXIF metadata

Often cited. Almost always wrong. EXIF is editable in fifteen seconds with ExifTool or any of dozens of free online editors. Treat EXIF as a hint to investigate, never as evidence. We wrote a whole post on why EXIF metadata isn't proof.

Error Level Analysis (ELA) and noise residuals

Tools like FotoForensics and Forensically can sometimes spot crude edits by visualizing compression inconsistencies between edited regions and the surrounding pixels. The catch:

• Skilled attackers defeat ELA by re-encoding the full output at uniform quality.
• ELA produces false positives on legitimately-composited images (screenshots that include a status bar, screenshots of windowed apps).
• The detection rate degrades steadily as editing tools mature.

ELA is most useful in the “quick sanity check” mode — if a screenshot is allegedly direct-capture but ELA shows obvious recompression artifacts in a specific region, that's a real lead. But the absence of ELA signal doesn't mean the screenshot is clean.

AI image detectors

Hive, Sensity, Optic, and others classify whether an image is likely AI-generated. The classifiers worked moderately well in 2023; in 2026 they're close to chance on competent fakes and decisively beaten by adversarial post-processing. We covered the tradeoffs at vs. AI detectors. Useful as a weak signal alongside other evidence; never decisive on its own.

Visual inspection

The cheapest and sometimes most effective heuristic. Look for:

• UI elements that don't match the claimed platform's real chrome (wrong status bar icons, wrong font, wrong timestamp format).
• Text rendering inconsistencies — kerning that doesn't match how the real app renders the same string.
• Anachronisms — UI elements that didn't exist at the claimed capture date, accounts that didn't exist yet, features that weren't rolled out.
• Resolution / aspect ratio mismatches with the claimed device.

Visual inspection catches lazy fakes. It doesn't catch careful fakes. And it requires the reviewer to know the platform's chrome well enough to spot inconsistencies.

The journalism workflow that actually holds

Professional newsrooms have converged on a four-step protocol for screenshot-based stories. Each step is independent; weak evidence in one step is not necessarily fatal if the other steps are strong.

1. Provenance. If the screenshot is sealed (receipts.you, C2PA, qualified timestamp), verify the seal. If not, ask the source whether they can re-capture and seal forward; if the original event has passed, this layer is blank.
2. Independent corroboration. Does the archive.today / Wayback / third-party scrape have the same content at a compatible timestamp? Did multiple witnesses see the live post? Does the platform's own audit log (if accessible) confirm?
3. Source interview. Where did the source get the screenshot? Can the source seal-forward (capture additional evidence with provenance)? Has the source been reliable on previous stories?
4. Subject right of reply. Has the subject been asked to confirm or deny? Their response (denial, silence, confirmation) is itself evidence.

Receipts strengthen the provenance layer; they don't replace the others. The honest framing is consistent across the protocol: a sealed screenshot proves WHEN a file existed, not WHAT it depicts. The other layers prove the depiction.

What to actually do, by situation

• You have a screenshot you might need. Seal it on /seal. Ten seconds. The receipt is durable, anonymous, free.
• Someone sent you a sealed screenshot. Drop on /verify. The verdict tells you what you need to know.
• Someone sent you an unsealed screenshot. Ask for the source. If they can't produce one, hesitate before treating it as evidence. The screenshot may be real and unsealed; it may be fake. Cryptography can't help; journalism workflow has to.
• You're writing a story based on a screenshot. Apply the four-step newsroom protocol above. Be explicit in the piece about which layers you verified and which you couldn't.

The defensible posture in 2026 is: cryptographic verification when available, defensive skepticism when not. The arms race on detection of unsealed content is unwinnable on the detection side; the win comes from sealing real captures forward, so the verification step is always available on the evidence that matters.

For the related question of why EXIF dates shouldn't be cited as proof, see EXIF metadata isn't proof.