Handling contract PDFs safely
Last updated: 2026-07-27
Sending contracts as PDFs is so routine that it is easy to stop noticing where things go wrong. Leaks almost never come from a dramatic breach. They come from small, ordinary mistakes: information riding along inside the file, an autocompleted email address, a paragraph that looked deleted but was not.
A PDF carries more than what you can see
Every PDF stores metadata alongside its visible content: the author name, the application and version that produced the file, creation and modification timestamps, and sometimes a title or keywords inherited from the source document. When a contract is exported from Word or Google Docs, the author field usually picks up whoever's account created the original — often not the person sending it. Some export paths also embed the source file path, quietly revealing an internal share name or a Windows username.
None of this is catastrophic on its own, but none of it is information the counterparty needs. It can reveal who actually drafted the agreement, that you reused a template from a different deal, or that the document was edited twenty minutes before the meeting. Checking is easy: open File → Properties in almost any PDF viewer and the fields are right there. Many tools can also strip them on export.
Covering something up is not the same as removing it
This is the most common and most damaging mistake in the whole category. To hide a price or a personal detail, people draw a black rectangle over it. That is not deletion. In a PDF, a rectangle is simply another object drawn on top; the text underneath remains fully intact. Anyone can select that region, copy it, or run text extraction and read exactly what you thought you had hidden.
Real removal requires a redaction feature that deletes the underlying text objects rather than obscuring them. If your tool lacks one, a reliable fallback is to rasterize the affected pages — convert them to images and rebuild the PDF. You lose selectable text and some sharpness, but nothing remains underneath to extract.
Email is itself a risk surface
Misdirected email is the leading cause of contract leaks by a wide margin. Autocomplete fills in a similar-looking address, the send button gets pressed, and the attachment is gone. Recall features work only inside the same mail system, and only if the recipient has not opened the message.
Even a correctly addressed contract leaves your control the moment it sends. The attachment now exists on the recipient's mail server, in their downloads folder, in their organization's backups, and in any forward they send. If it contains personal data, that proliferation is also a GDPR concern: you have created copies you can neither inventory nor delete on request. For sensitive agreements, a link with an expiry and access controls beats an attachment.
A password and encryption are not the same thing
PDFs support two kinds of password offering very different protection. The first is the user password, required to open the document. That one is real encryption — modern PDF versions use AES-256, and without it the content genuinely cannot be decrypted. The caveat is that weak passwords fall to brute force, so it needs to be long and unpredictable rather than the project code name.
The second is the owner password, or permissions password, which restricts printing, copying, or editing. This is not encryption. It is a flag inside the file asking viewers to enforce a restriction, and plenty of tools ignore it outright. Marking a contract as no-print does not stop anyone from printing it.
One more very common error: sending the encrypted file and its password in the same email defeats the purpose entirely. Send the password through a different channel.
What an image stamp does and does not do
Placing a signature or company stamp image onto a contract page and exporting a new PDF is an extremely common workflow. The result looks like an executed document, and the image is fixed to the page so it will not shift. This is precisely what a tool like StickPDF does, and because it runs entirely in the browser, the signed contract never has to be uploaded to a third-party server to get there.
What that stamp does not do is equally important. It provides no tamper detection. If someone alters a payment amount and re-applies the same signature image, nothing in the file reveals it. The image can also be extracted and reused on an unrelated document, which is why signature and stamp graphics deserve care — a scanned signature sitting in a shared team folder is a liability. If you need the document to prove it has not been altered since signing, an image cannot do that; a certificate-based digital signature can.
Always keep an untouched original
The simplest habit, and the one most often skipped: never overwrite the original when producing a signed or amended version. Sooner or later someone needs to establish which version was actually received, and a chain of files that quietly replaced each other cannot answer that. Date and version the filenames, and keep originals in a folder you never edit.
To go one step further, record a hash of the original — shasum -a 256 filename on macOS or Linux, certutil -hashfile filename SHA256 on Windows. Noting that value in the meeting record gives you a cheap, durable way to show later that the file has not changed.
In short: check metadata before it leaves, distinguish covering from deleting, separate the file from its password, and preserve the original. Whether a given signing method is legally sufficient for your agreement is a question for your counsel, not for a file-handling checklist.