How SignThis seals a signed document, and how anyone can verify it

The idea: a record everyone can check

When two parties sign a paper contract, each keeps a copy and either can produce it later. E-signature services often replace that with "trust our database". We think the better answer is to put the evidence inside the file each party receives, in a standard format, so that it can be checked with ordinary tools years later, whether or not SignThis is still running.

Everything below follows from that goal.

Step 1: the document is frozen when it is sent

A sender uploads a PDF, places the fields and adds the signers. At the moment of sending, the PDF and the field layout are frozen, and SignThis records a SHA-256 fingerprint of each. Nobody, including the sender, can edit that version afterwards. If something needs to change, the sender sends a corrected version and everyone signs that one.

This closes the oldest trick in document signing: swapping a page after some people have already signed.

Step 2: every step is written to a hash-chained audit trail

Each event for a document is appended to an audit trail: sent, viewed, consent given, signed or declined, completed. Each entry includes the SHA-256 hash of the entry before it. That is what "hash-chained" means, and it has one useful property: you cannot quietly remove or rewrite an entry in the middle, because every later entry would stop matching.

The head of that chain is printed on the audit certificate that comes with every completed document, so the record held by each party pins down the whole history.

Step 3: each signer is reached, informed and asked

A signer does not need an account. Each one receives a personal link at their email address. Before signing they:

1. open the document through that link, optionally after entering an access code the sender gave them separately;
2. agree to use electronic records and signatures, after seeing the disclosure;
3. review and complete the fields assigned to them;
4. confirm with an explicit signing action, which is bound to the fingerprints of the original file and the field layout from Step 1.

After five wrong access codes, that signer is locked out for 15 minutes. Signing links, sign-in and email sending are rate-limited.

The audit certificate records how each signer was reached and when they agreed. It is careful about what that shows: a link delivered to a mailbox demonstrates control of that mailbox. It does not, by itself, prove a person's real-world identity, and neither does the look of a signature.

Step 4: the finished PDF is sealed and timestamped

When the last person signs, SignThis builds the final document: the original pages with the completed fields drawn onto them, followed by a certificate of completion. Then it seals the whole file.

• The seal is a standard PDF digital signature in the PAdES family (a detached CAdES signature, the ETSI.CAdES.detached format). It covers every byte of the file, so any later change is detectable by any reader that validates signatures.
• The seal carries an RFC 3161 timestamp from DigiCert, an independent timestamp authority. Only a hash of the seal is sent to DigiCert, never the document. The timestamp shows when the seal was applied without relying on our clock. As the service runs today, a document is not marked complete without it.
• A separate audit certificate is produced and sealed the same way. It names the sealed document's SHA-256 fingerprint, so the two files point at each other.

Step 5: everyone receives the same bytes

Every party gets the sealed PDF and the audit certificate by email. The copies are byte-for-byte identical, and the file's fingerprint is re-checked against the record before a copy is attached. The completion email also states the record code and the fingerprint.

From that point the evidence is in the recipients' hands. Emailed copies cannot be recalled, which is the point: no one, including us, can later alter what each party holds.

How to verify a completed document

Offline, with only the file

Open the PDF in Adobe Acrobat Reader, or another reader that validates signatures, and open the signature panel. It reports whether the document has been modified since the seal was applied, and shows the embedded timestamp. This check needs nothing from SignThis.

Online, without uploading the file

The verify page computes the file's SHA-256 fingerprint in your browser and sends only that fingerprint. It answers whether the file is byte-for-byte the sealed copy of a completed record, and reports whether that record's audit trail is intact. The audit certificate's QR code leads to the same check.

For a walk-through that works with any signed PDF, see how to check whether a signed PDF has been altered.

How stored documents are protected

• In transit: every connection uses TLS.
• At rest: before anything is stored, the application encrypts documents, signatures, field values, names, email addresses and audit details with AES-256-GCM. Each document has its own keys.
• Root keys that protect those keys are held as Cloudflare Worker secrets, not in the code, the database or file storage.
• Deletion destroys a document's keys (crypto-shredding), so a copy left in storage or a backup cannot be read. Database backups may hold deleted data for up to 35 days.

What this design does not do

Security writing that lists only strengths is advertising. These are the limits, and they are also on our security page.

• It is not end-to-end encryption. Our servers must read a document to display, stamp, seal and email it, so the running service can decrypt your data. The encryption protects against leaked storage, leaked backups and anyone browsing stored data, not against someone who took over the running service or its root keys.
• Email leaves our protection. The sealed PDF we send is as safe as each recipient's mailbox. Workspaces that prefer it can deliver completed documents by private link instead of attachment.
• Email-link authentication is not identity verification. There is no government-ID check and no notarization.
• There has been no independent penetration test yet.
• It is not for protected health information. SignThis is not currently available for PHI.

Common questions

What is a PAdES seal?

PAdES is the European standard for digital signatures inside PDF files. A PAdES seal stores a cryptographic signature over the file's bytes inside the PDF itself, so any standard reader can check that nothing changed. SignThis applies one seal to each completed document on behalf of the service; it is not a personal certificate for each signer.

What does an RFC 3161 timestamp add?

It is a signed statement from an independent timestamp authority that a particular fingerprint existed at a particular time. It lets someone verify when a document was sealed without trusting the clock of the service that sealed it.

Can SignThis change a document after it is sealed?

Not without it showing. Any change to a sealed file breaks the seal, and every party already holds an identical sealed copy and its fingerprint.

What happens to verification if SignThis disappears?

The offline check keeps working, because the seal and timestamp are inside the PDF. The online verify page would not. That is why the offline check is the primary one.

Do signers need an account or an app?

No. Each signer uses a personal link in their browser, on a phone or a computer.