Plain English — promise
A checksum isn't proof
A SHA-256 hash tells you a file matches a fingerprint. It can't tell you who made the fingerprint, when — or stop someone from quietly making a new one. Here's the difference between a hash and a sealed document, and why it matters in a dispute.
Side by side
A hash proves…
…that a file matches a fingerprint you already trust. That's all. If someone edits the document, they can hash their edited copy and hand you the new fingerprint with a straight face.
A seal proves…
…the fingerprint itself. The hash is signed, so nobody can re-sign a tampered copy without the key — and a timestamp witnesses when the seal existed. Editing the document doesn't just change the hash; it breaks the signature, loudly.
The re-hash problem
Checksums fail exactly when you need them: against a motivated editor. A hash published next to the file it fingerprints is a promise from whoever controls both. Unless the fingerprint is anchored to something the editor can't reproduce — a signature key, a timestamp authority — “the hash matches” only means “this is the copy I was given.”
What an Omitly seal adds
Every sealed PDF carries an Ed25519 signature over its digest, and — whenever a timestamp authority is reachable at sealing — an RFC 3161 timestamp witnessing when the seal existed. Anyone can verify it — free, offline, without an account — using the app or the free npm verifier. A hybrid signature adding ML-DSA-87 alongside classical ECDSA P-384 is on our roadmap, not shipped yet.
The signature idea itself, explained without the maths: What is Ed25519? →
Seal it, don't just hash it
Redact and seal in one step — and give the other side a way to verify you did.