When the second party signs, Send NDA prints the agreement to a PDF and seals it. Sealed means stored once, with its SHA-256 recorded in the signing record, and never written again. That PDF is the one both of you get by email and the one you download afterwards from the NDA's page or your dashboard. It comes with a second sealed PDF, its signing certificate.
What gets sealed
The agreement you both signed is fixed earlier than the PDF. When the NDA goes out, Send NDA renders the contract once, stores that HTML, and records its SHA-256 in the sent event. From then on both parties see that stored copy, not a fresh render. An amendment before anyone signs is a fresh invitation: it renders and stores again, and the amended event records the new SHA-256 beside the one it superseded. A template deployed between the sending and the last signature can't reach the agreement, and both parties sign exactly the same text.
At completion, the sealed PDF is printed from that stored agreement plus the signatures. Three things are stored:
- the PDF, and its SHA-256;
- the HTML it was printed from, and its SHA-256;
- a snapshot of every input that shaped the agreement: both parties' names, email addresses, addresses and company details, whether the recipient signs for themselves, who discloses, the AI tools level, the purpose, the optional clauses, both durations, and the template version.
The stylesheet and fonts are copied into the stored HTML instead of linked, so it renders the same years from now, after the site's own styles have moved on.
Where the agreement carries a text in a party's own language beside the English, both texts are in that one document, under the one hash.
Before anyone has signed, a party can download the agreement as it stands from the NDA's page. That copy is printed on request, marked Not signed on every page and stored nowhere. It carries no seal and the verify page can't check it; the sealed PDF is the one Send NDA stands behind.
Why it can't change
Once stored, the sealed document can't be edited or deleted by the application. The only thing it may still update is when the completion emails went out. A later version of the template, a change in the database, or a redesign of the site leaves the stored PDF and its recorded hash alone.
That's a statement about the application, not a promise that no file on any disk can ever be touched. It's why the hash sits in the chained record as well: a file that doesn't match its recorded SHA-256 shows it was changed.
The order of things
Sealing is a barrier. The PDF is printed, stored and recorded in a frozen event, then the signing certificate is printed, stored and recorded in a certified event, before any completion email is sent. The emails attach those same stored files. If a step fails, the job runs again, five attempts in all, without sealing twice or mailing twice. Each sealed file is named by its own hash and never written over. After the emails, the hashes of the PDF, the certificate and the record's last entry are stamped with OpenTimestamps, and once a Bitcoin block confirms the stamp the record gains an anchored entry naming the block.
Right after the second signature, the PDF may take a moment. Download it before it's ready and you're asked to try again in a moment.
The format
The PDF is printed on Letter paper when the sender's address is in the US or Canada, and on A4 everywhere else. The first page opens on a band with the parties, the time of the last signature and the agreement's id. The agreement's own text is set in Spectral, as on the signing page, and a clause heading never ends a page. The signatures open a page of their own, set in the handwriting face you saw when signing, or showing the signature you drew. Each signature carries the signer's name, the company they signed for if any, and the date, time in UTC and IP address of the signature. Every page carries the agreement's title and the parties at its foot, with the page number.
The signing certificate
The certificate is a separate PDF, and it states that it's an official Send NDA document. It holds:
- both parties: name, company, email address, and the time, IP address and browser of their signature;
- the SHA-256 of the agreement text both of you signed, of the sealed PDF, and of the HTML it was printed from;
- every event in the signing record up to the seal, each with its time in UTC and its hash, and that the chain held when the certificate was issued: a chain that doesn't hold gets no certificate;
- where to check both documents.
It's a PDF of its own because it records the sealed agreement's hash, and a file can't hold its own hash. It's sealed the same way: stored once, with its SHA-256 in the certified event. The completion emails attach it beside the PDF, and the NDA's page offers it in its Download menu: the agreement and certificate together as a ZIP, or each PDF on its own.
To check a PDF someone sends you, see Verify a copy.