How to check if a file is authentic

A source sends you a document. A press release lands in your inbox from an address you don't quite recognize. A screenshot of a "leaked memo" is going around. Before you repeat any of it, you want to know two things: did it really come from who it claims to, and is this the exact file they made, down to the last byte?

If the file carries a provenance stamp, both questions take about 30 seconds to answer, free, with no account. This guide covers how to run the check and, just as important, how to read each of the three results honestly.

The quick check

1. Get the actual file

   Verification works on exact bytes, so you need the original file, not a screenshot of it and not a photo of a screen. Ask for the file as an attachment or a direct download.

2. Drop it at the verify page

   Go to makemark.io/verify and drop the file. Your browser computes its fingerprint (a SHA-256 hash) locally; the file itself is never uploaded, so confidential material stays confidential.

3. Read the result

   You'll see one of three outcomes: a match, conflicting claims, or no record. Each means something specific, covered below.

Reading the result

A match

The file's fingerprint matches a stamp on the public record. The record shows who stamped it and when, and the match is byte-for-byte: this is exactly the file they sealed, unedited.

Look at the identity tier. An Official badge means a hand-vetted organization that proved control of its domain, the strongest signal. A Verified badge means the publisher proved control of a handle or domain. A plain account proves nothing about who's behind it, but the timestamp still holds. You'll also see two timestamps: when the publisher signed the stamp, and when it was anchored to the public record. The anchored one is the hard evidence.

Conflicting claims

More than one signer has claimed these exact bytes. The result lists every claim, earliest-anchored first, and flags the conflict rather than hiding it. This is where your judgment comes in: an early stamp from a verified newsroom and a later one from an anonymous account tell a fairly clear story. Two early stamps from two verified identities tell you to pick up the phone.

No record

Nobody stamped this exact file. Read this one carefully: it is not evidence of forgery. The overwhelming majority of files in the world were never stamped. No record means the check can't help you, not that the file is fake. If provenance matters, go back to the sender and ask for the original file, or ask them to stamp it; stamping takes about 30 seconds and is free.

The screenshot problem

The most common verification mistake is checking the wrong bytes. Messaging apps and social platforms recompress images. Email clients sometimes re-encode attachments. A screenshot is an entirely new file. Any of these will fail the check even if the underlying content is genuine, because the bytes are different.

So a failed match on a copy isn't a verdict either; it's a prompt to chase the original. This is also why embedded credentials like C2PA Content Credentials struggle on social platforms: metadata gets stripped in transit. A hash-based record lives outside the file, so the record survives, but you still need the original bytes to demonstrate the match.

What a match doesn't tell you

Being precise about the limits: a stamp proves that a specific identity possessed these exact bytes at a specific moment. It does not prove the content is true. A verified publisher can stamp a false statement; a stamp on a document doesn't make its numbers right. Provenance answers "who and when," and it answers those well. "Is it accurate" is still journalism.

For the deeper mechanics, daily Arweave anchoring (with optional Base support), offline signature and Merkle checks, and separate public-anchor verification, see the docs and the MIT-licensed offline verifier in the @tatastu/mark npm package.

Common questions