Verify a signed PDF yourself, with one command

When an envelope completes, closeit.fast appends the certificate of completion to the document and hashes the finished file with SHA-256. The digest is stored beside the envelope and shown to you.

Most people read that as a feature. It is better understood as a promise you can audit, because the whole point of a hash is that checking it requires nothing from us. Not our software, not our servers, not our continued existence as a company.

What a digest actually is

SHA-256 reads every byte of a file and produces a 64-character hexadecimal string. The same bytes always produce the same string. Different bytes produce a wildly different one — changing a single character in a hundred-page contract changes roughly half the digits, with no resemblance to the original.

There is no way to work backwards from the digest to the file, and no practical way to construct a different file that produces the same digest. That is the entire mechanism. It is arithmetic, it is public, and it has no opinion about who is running it.

The command

Download the completed PDF from your dashboard, then run one of these against it.

macOS and Linux

shasum -a 256 agreement.pdf

Or, on most Linux distributions:

sha256sum agreement.pdf

Windows

In Command Prompt:

certutil -hashfile agreement.pdf SHA256

Or in PowerShell, which formats it more readably:

Get-FileHash agreement.pdf -Algorithm SHA256

Compare the output to the digest shown against the envelope. They match character for character, or the file in your hands is not the file that was sealed. There is no third outcome and no interpretation involved.

This is the rare security claim that you can falsify yourself in about ten seconds, on a machine we have never touched.

Five ordinary things that break a hash

Here is the part that causes real confusion, and that almost no vendor documentation mentions.

A hash covers bytes, not appearance. Two PDFs can look identical on screen, print identically, contain the same words in the same order, and hash differently. Several completely innocent actions will do this:

1. Print to PDF. This does not copy the file. It renders it and writes a brand new one, with new internal structure and new metadata. The result is a different file that happens to look the same.
2. Save as, or Export, from a PDF viewer. Preview on macOS and Acrobat both rewrite the file on save, even when you changed nothing. Some viewers do it merely on opening and closing.
3. Optimising or compressing. Any “reduce file size” tool rebuilds the document from scratch.
4. Adding a watermark, a stamp, or a page. Obviously a change, but people often think of it as an annotation layered on top rather than a modification of the file.
5. Reordering, rotating or deleting pages. Same again.

So a mismatch means the bytes are not the ones that were sealed. It does not automatically mean somebody tampered with your contract. Far more often it means somebody helpfully re-saved it.

The practical rule follows directly: archive the file exactly as downloaded. Do not open and re-save it, do not run it through a compressor, do not print it to PDF for tidiness. If you need a working copy, copy the file rather than re-export it. A plain file copy preserves bytes and therefore preserves the digest.

Why this matters beyond peace of mind

On 1 December 2017 two rules were added to the Federal Rules of Evidence. Rule 902(14) provides that data copied from an electronic device, storage medium or file can be self-authenticating when it is authenticated by a hash value compared by a qualified person, subject to a written certification and reasonable advance notice to the other side.

That rule was written with precisely this in mind. A document sealed with a published digest, where the comparison can be performed by anybody with a laptop, is the fact pattern the rule contemplates.

Self-authenticating means the record may get in without a live witness to establish it. It does not mean it wins the argument, and anyone claiming their hash makes a document court-admissible is describing a decision that belongs to a judge.

What the digest does not cover

Worth restating, because a hash is easy to over-read:

• It says nothing about who signed. That is the audit trail's job, and even the trail has limits.
• It says nothing about intent, authority to bind a company, or whether the terms are enforceable.
• It proves integrity from the moment of sealing onward. It has no view on anything that happened before.
• It is tamper-evident, not tamper-proof. Nothing stops a file being altered. The digest guarantees only that alteration becomes detectable.

Those are real boundaries and we would rather write them down than let a green checkmark imply something broader.

Try it on something real

The free tier produces exactly the same sealed PDF and the same certificate as the paid plan. Send yourself a one-page document, sign it, download the result and run the command above. Then open it in a PDF viewer, save it, and run the command again to watch the digest change.

Ten minutes of that teaches more about what these systems can and cannot promise than any amount of reading, including this.