How tamper-evident signed PDFs work
A tamper-evident signed PDF is one where any change to the file after signing can be detected, through a cryptographic hash computed at the moment signing completed and compared against the document's current state whenever it's checked. This is what actually protects a signed document's integrity — not the visual appearance of the signature on the page, which tells you nothing about whether the surrounding content has changed.
What a cryptographic hash actually is
A hash function takes any input (in this case, the full content of the signed PDF) and produces a fixed-length string of characters — a kind of fingerprint. The same input always produces the same hash, and even a tiny change to the input (a single character, a changed date, an altered clause) produces a completely different hash. This is the property that makes hashing useful for detecting tampering: you don't need to compare the entire document byte by byte, just compare its current hash against the one recorded when it was signed.
Why this matters more than the signature itself
A drawn or typed signature on a page is just an image — it doesn't carry any information about whether the rest of the document has been altered since it was applied. Someone could, in principle, take a validly signed document, modify the text on a page the signature doesn't directly overlap, and the signature image would look completely identical either way. The hash is what actually catches this: if the modified document's hash doesn't match the one recorded at signing time, the mismatch reveals that something changed, regardless of how convincing the signature still looks.
When the hash gets computed
The hash is typically computed once the document is finalized — after every required signer has completed their part and the final signed PDF, with every signature embedded, is generated. That hash is then stored as part of the signing record and included in the completion certificate.
How verification actually works
To check whether a signed document is still intact, you compute the hash of the file you currently have and compare it against the hash recorded at signing time. If they match, the file is byte-for-byte identical to what was signed. If they don't match, something has changed — even a change that looks cosmetically minor, like a reformatted date, would produce a completely different hash and would be flagged as a mismatch. See How to verify a signed document for how this works from a practical, non-technical perspective.
What tamper-evidence doesn't do
Hashing detects that something changed — it doesn't prevent someone from attempting to change a document, and it doesn't by itself tell you what specifically changed or who made the change. For that level of detail, you'd need the surrounding audit trail, which separately tracks who did what and when during the legitimate signing process. See What an e-signature audit trail contains for that complementary mechanism.
Hashing the document vs. hashing the audit trail
These are two related but separate applications of the same underlying technique. Document hashing protects the signed PDF file itself. A hash-chained audit trail applies the same principle to the sequence of events logged during signing, where each entry includes the hash of the previous one — so tampering with the historical record of what happened, not just the final file, is also detectable.
Why a timestamp adds another layer
Knowing that a document's hash hasn't changed tells you the content is intact, but it doesn't independently prove when it was signed, if that timing is ever in question. An independent timestamp conforming to RFC 3161, applied at signing time, adds a verifiable record of when the document (and its hash) existed, without relying solely on the signing platform's own internal clock. See RFC 3161 timestamps explained for how that works.
This matters most when a signature is ever disputed
If a signed document's validity is ever challenged, the ability to show that the hash of the document in question still matches the hash recorded at signing time is direct, concrete evidence that it hasn't been altered — considerably stronger evidence than simply pointing at the signature and asserting the document is unchanged. See E-signature evidence: what counts in a dispute for how this fits into the broader evidentiary picture.
Esignapi's approach to document integrity
Every document signed through Esignapi has a SHA-256 hash computed once signing completes, stored alongside an RFC 3161 timestamp and the full audit trail, and included in the completion certificate for later verification.
Checking a document's hash yourself, conceptually
You don't need to understand the underlying math to make use of this protection — practically, verification works by comparing the hash recorded at signing time (available through the platform's certificate or API) against a freshly computed hash of the document file you currently have. If a platform exposes this through its API or a verification page, you can confirm a document's integrity without needing any special cryptographic expertise yourself, since the comparison itself is a simple match-or-mismatch result.
Why printing and rescanning breaks tamper-evidence
A signed PDF's hash covers the exact digital file — if you print a signed document and then scan it back in, the resulting file is a completely different set of bytes (a scanned image rather than the original digital PDF), even though it looks identical to a human reading it. This means the original hash no longer applies, and the scanned version can't be verified against it. If document integrity verification matters for a particular document, keep and share the original digital file rather than a printed-and-rescanned copy, which loses this protection entirely.
Verify document integrity automatically
Esignapi's API exposes the document hash and audit trail data for every signature request, so you can build integrity verification directly into your own systems.
Frequently asked questions
Can a hash be reversed to reveal the original document content?
No — a cryptographic hash is a one-way function. You can't reconstruct the original document from its hash; you can only compare a known document's hash against a previously recorded one to check whether they match.
Generally yes — even metadata changes alter the underlying file content, which changes the hash. This is part of why even seemingly minor edits to a finalized signed document should be avoided entirely rather than assumed to be harmless.
What hashing algorithm is commonly used for this?
SHA-256 is a widely used standard for this kind of integrity verification across the industry, valued for being both secure against practical attacks and computationally efficient to calculate and verify.
If a document's hash doesn't match, does that prove fraud?
It proves the file has changed since it was signed — it doesn't by itself tell you why, or by whom. That said, a mismatch is a serious red flag that the document you're looking at isn't the one that was actually signed, and it's worth investigating further.
Is hashing the same thing as encryption?
No — encryption is reversible with the right key and is meant to protect confidentiality. Hashing is one-directional and is meant to detect changes, not to hide content. Both can be used together, but they serve different purposes.