What a Digital Signature Is Not
A digital signature is not a scanned image of your handwritten signature dropped onto a document. That's an image. It proves nothing about who created the file or whether the content has changed since signing. Anyone with a graphics editor can copy that image to any document.
A cryptographic digital signature is something fundamentally different. It's a mathematical proof, derived from the document's actual content and tied to a private key that only the signer possesses, that simultaneously identifies the signer and guarantees the document hasn't been altered. Change even a single byte after signing and the signature becomes invalid. (Wikipedia's digital signature article covers the underlying math and legal status by jurisdiction.)
Understanding how this works is worth five minutes — it explains why digital signatures are trusted for contracts, and why a scanned signature isn't.
The Signing Process
Digital signatures use asymmetric cryptography (also called public-key cryptography). The signer has two mathematically linked keys: a private key that they keep secret and a public key that they share with anyone who needs to verify their signatures.
Here's what happens when you digitally sign a PDF:
Hash the document. A cryptographic hash function (SHA-256 is standard) processes the entire document content and produces a fixed-length digest — typically 256 bits. This digest is a fingerprint of the document. Change anything in the document and the hash changes completely.
Sign the hash with your private key. The private key is used to cryptographically sign the hash digest — in RSA-based schemes this involves a modular exponentiation with the private key; in ECDSA it involves elliptic-curve arithmetic. The result is the digital signature, stored in the PDF alongside the document content.
Embed the signer's certificate. The PDF also stores the signer's public key certificate, which contains their public key and identity information, signed by a Certificate Authority (CA).
Document content → SHA-256 hash → Signed with private key → Signature bytesThat's it. The signature is essentially: "here is proof that someone with this private key saw this exact version of this document."
The Verification Process
Anyone with the signer's public key can verify the signature. This is the important asymmetry: signing requires the private key, but verification is open to everyone.
Verify the signature. Use the signer's public key (from the embedded certificate) to verify the signature bytes and recover the original hash. In RSA schemes this is mathematically the inverse of signing; in ECDSA the algorithm verifies the signature directly without recovering a plaintext hash.
Hash the document again. Compute a fresh SHA-256 hash of the document content as it exists now.
Compare the two hashes. If they match, the document hasn't been modified since signing. If they don't match, something changed — either the document was tampered with, or the signature is invalid.
PDF viewers like Adobe Acrobat and Foxit do this automatically and show a green checkmark or a warning. When a document fails verification, it's either tampered, or the certificate chain has a problem.
Certificate Chains and Trust Anchors
How do you know the signer's public key actually belongs to who they claim to be? That's where Certificate Authorities come in.
A digital certificate is a public key bundled with identity information (name, organization, email) and a digital signature from a CA that vouches for it. The CA's signature on the certificate can itself be verified using the CA's public key — and that CA's certificate is signed by a root CA. This chain continues up to a root certificate that your operating system or PDF viewer pre-installs as trusted.
When Acrobat says "signed by Alice Smith, identity verified," it means: Alice's certificate was signed by a CA your system trusts, and the document hasn't changed since Alice's private key signed it. The X.509 certificate format and chain validation rules are formally specified in RFC 5280.
This is why self-signed certificates (where you sign your own certificate) show warnings — there's no trusted third party vouching for the identity claim. Self-signed signatures still prove document integrity; they just don't prove identity.
PDF Encryption and Permissions
Separate from signatures, PDF supports two types of password protection, using AES-256 encryption (older files may use 128-bit RC4, which is now considered weak):
User password (document open password): Required to open the file at all. If you don't have this password, you see nothing. The content is encrypted and unreadable without it.
Owner password (permissions password): The file opens without it, but it restricts what you can do: print, copy text, annotate, fill forms, modify content. These restrictions are enforced by compliant PDF viewers. They can be bypassed by tools that ignore permissions, so they're not a security measure against a determined adversary — they're a policy signal for compliant software.
Encryption: AES-256
User password: required to open
Owner password: restricts print/copy/modifyA password-protected PDF with a strong user password and no owner password is genuinely secure for content protection — the encrypted ciphertext is meaningless without the password. The PDF Merge tool handles already-unlocked PDFs; if you're working with locked PDFs programmatically, you need the password to decrypt before processing.
Long-Term Validation (LTV)
Signatures depend on certificate validity. But certificates expire, and CAs can revoke certificates if a private key is compromised. What happens to a signed document years after the signing certificate expires?
Long-Term Validation (LTV) is the PDF standard's answer. At signing time, the document embeds:
- The complete certificate chain (not just the signer's certificate)
- A certificate revocation check result (via OCSP or a CRL)
- A timestamp from a trusted timestamping authority
The embedded timestamp proves when the signature was created. The embedded revocation status proves the certificate was valid at that time. Future verifiers don't need to query any online service — all the validation evidence is inside the PDF. This is how signed contracts remain cryptographically verifiable decades later.
Without LTV, a signature validated years later might fail because the CA's OCSP responder is gone, the CRL is no longer published, or the certificate chain can't be constructed. LTV archives everything needed for perpetual verification. The European ETSI PAdES standard defines the LTV profile in detail and is the basis for many regulated electronic signature workflows.
For a secure hash of document contents outside of PDF — useful for verifying file integrity after download or transmission — the Hash Generator computes SHA-256 and other algorithm outputs directly in your browser. For background on the asymmetric cryptography that powers digital signatures, Public Key Cryptography Explained covers the math and real-world usage. And for the foundational PDF file structure that signatures attach to, How PDF Works explains the xref table, content streams, and how signature objects are stored in the PDF body.
FAQ
Is a scanned image of my signature legally binding?
In some jurisdictions for some uses, yes — most US e-signature laws (E-SIGN Act, UETA) accept "any electronic process" demonstrating intent. But a scanned signature image proves nothing cryptographically: anyone with image editing software can copy it elsewhere, and if the document changes after signing, there's no way to detect it. For high-value contracts, use a real cryptographic digital signature; for low-stakes internal forms, a typed name or scanned image is usually fine.
What's the difference between an electronic signature and a digital signature?
Electronic signature is a broad legal term covering any electronic indication of intent — a typed name, a clicked checkbox, a drawn signature, or a cryptographic signature. Digital signature is a specific technical implementation using public-key cryptography to produce a verifiable, tamper-evident proof. All digital signatures are electronic signatures; not all electronic signatures are digital signatures.
How do I get a digital certificate for signing PDFs?
Three paths: (1) buy one from a Certificate Authority like DigiCert, Sectigo, or GlobalSign for $100-500/year — these give you publicly trusted identity. (2) Use a service like Adobe Sign or DocuSign that handles certificates for you. (3) Generate a self-signed certificate for free (Acrobat lets you do this). Self-signed signatures prove document integrity but show "identity not verified" warnings; CA-issued certificates show as fully trusted.
Can a digitally signed PDF still be edited?
The original signed version cannot — any modification breaks the signature. But PDF supports incremental updates: Acrobat can append form fills, comments, or additional signatures while preserving the original signature's validity. The original signed bytes are immutable; the file just grows with appended changes. PAdES profiles define exactly which kinds of additions are allowed without breaking signatures.
What happens to digitally signed PDFs after the certificate expires?
Without LTV (Long-Term Validation), expired certificates make signature validation fail because verifiers can't determine if the cert was valid at signing time. With LTV, the PDF embeds the full certificate chain, revocation status, and a timestamp — all the evidence needed for perpetual verification, even decades later. For any contract you might need to verify in 10+ years, always sign with LTV enabled.
Is the password on my PDF actually secure?
If it's a strong user password (open password) on a modern PDF using AES-256, yes — the content is genuinely encrypted and unreadable without the password. If it's an owner password (permissions password) restricting print/copy, no — those restrictions are policy hints that any non-compliant tool can ignore. Don't confuse "password to open" with "password to copy"; only the first provides real security.
Can I sign a PDF programmatically without Adobe Acrobat?
Yes — libraries like iText (Java/.NET, commercial), PyHanko (Python), and node-signpdf (Node.js) handle PDF signing. You provide the certificate and private key, the library hashes the document, signs the hash, and embeds the signature object. The result is a signed PDF identical to what Acrobat would produce. For high-volume automated signing, these libraries are the production standard.
What's PAdES and do I need it?
PAdES (PDF Advanced Electronic Signatures) is the European ETSI standard for PDF signatures, defining four profiles: B-B (basic), B-T (with timestamp), B-LT (with revocation info for long-term), and B-LTA (long-term with archive timestamps). For EU regulated workflows (eIDAS-compliant signatures, contracts subject to EU law), PAdES is required. For US-only workflows under E-SIGN, basic PDF signatures usually suffice. Most modern signing tools support PAdES profiles as configurable options.