How PDF integrity checking works
A SHA-256 hash is a 64-character value computed from every byte of a file. Two identical files always produce the same hash; changing a single character produces a completely different one, and it is not feasible to craft a different file with the same hash. So if you know the hash a file had when it was signed, you can recompute it later and compare.
Checking a PDF sealed with OpenSigner
- Open the verifier.
- Drop in the PDF. Your browser recomputes its SHA-256 hash locally; the file is not uploaded.
- OpenSigner reads the seal embedded in the file and compares. A green VALID result means the file is byte-for-byte what was sealed. A red TAMPERED result means it changed after sealing.
If the file was re-saved by another app (for example "Print to PDF"), the seal is often removed, and the verifier will tell you no seal was found. That itself is a sign the file isn't the original.
Why a PDF can't simply contain its own hash
Writing a hash into a file changes the file, and therefore its hash. OpenSigner uses the same approach as standard PDF digital signatures: it reserves a fixed-length slot, hashes the file with that slot blanked, then fills the slot without moving any other byte. The verifier repeats exactly that calculation.
What a seal does not prove
A hash proves the file hasn't changed since it was sealed. It doesn't prove who sealed it, because anyone can seal a new file. For stronger assurance, the signer can send you the hash (or the certificate's QR link) through a separate channel, such as email or chat, so you can compare it with the file you received.
Checking any file's hash
For PDFs without an OpenSigner seal, you can still compare hashes if the sender gives you one. On Windows run certutil -hashfile file.pdf SHA256; on macOS or Linux run shasum -a 256 file.pdf.