[ Docs ](https://sendnda.com/docs)     

 [ Evidence ](https://sendnda.com/docs/evidence)     

The sealed PDF
==============

How a completed agreement is frozen, and why a later change cannot reach it.

 03

Evidence
--------

Article 2 of 3

 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](https://sendnda.com/docs/evidence/the-signing-record), and never written again. That PDF is the one both of you get by email and the one you download from your signing link afterwards.

What gets sealed
----------------

The agreement you both signed is fixed earlier than the PDF. At the first signature, Send NDA renders the contract once, stores that HTML, and records its SHA-256 in the `signed` event. From then on both parties see that stored copy, not a fresh render. A change to the template between the two signatures can't reach an agreement that's already half signed, and the second party signs exactly the text the first one did.

At completion, the sealed PDF is printed from that stored agreement plus the signature block. 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, 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.

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 before any completion email is sent, and the emails attach that same stored file. If a step fails, the job runs again, three attempts in all, without sealing twice or mailing twice.

Right after the second signature, the PDF may take a moment. Download it from your signing link before it's ready and you're asked to try again in a moment.

The format
----------

The PDF is printed on US legal paper with 18 mm margins at the top and bottom and 16 mm at the sides. The agreement's own text is set in Helvetica; signatures are set in the handwriting face you saw when signing. 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.

To check a PDF someone sends you, see [Verify a copy](https://sendnda.com/docs/evidence/verify-a-copy).

 Checked against the code on 21 September 2026.

 [   The signing record ](https://sendnda.com/docs/evidence/the-signing-record) [ Verify a copy   ](https://sendnda.com/docs/evidence/verify-a-copy)
