PDF Digital Signature
A PDF digital signature is a cryptographic mechanism that proves two things simultaneously: that a specific person or organisation signed the document (authentication), and that the document has not been altered since the signature was applied (integrity). It is distinct from a handwritten signature image — a scanned or drawn signature image is purely visual and provides no cryptographic guarantees.
PDF digital signatures are built on public-key cryptography (PKI). The signer possesses a private key (kept secret) and a corresponding public key distributed via an X.509 certificate. Signing involves computing a cryptographic hash of the document and encrypting it with the private key. Verification involves decrypting the hash with the signer's public key and comparing it with a freshly computed hash of the document — if they match, the document is intact and the signature is authentic.
How PDF digital signatures work technically
The PDF signature mechanism is built around the <code>/ByteRange</code> and <code>/Contents</code> entries in a PDF signature dictionary:
<strong>/ByteRange</strong> — An array of four integers: [offset1, length1, offset2, length2]. Specifies the byte ranges of the PDF that are covered by the signature. Together, these ranges cover the entire file except for the /Contents value itself (which contains the signature blob — it cannot sign itself). In a typical approval signature, the ranges cover everything except the /Contents field.
<strong>/Contents</strong> — The signature value as a hex-encoded byte string, typically a PKCS#7/CMS (Cryptographic Message Syntax) signed data object. This object contains the encrypted hash, the signer's X.509 certificate, optional OCSP response, and optional timestamp countersignature.
<strong>Signature types</strong>: <code>adbe.pkcs7.detached</code> — The most common signature type. A PKCS#7 detached signature where the signed data is not included in the /Contents — the document bytes themselves serve as the signed data. <code>adbe.pkcs7.sha1</code> — Older SHA-1 based type; deprecated in modern implementations. <code>ETSI.CAdES.detached</code> — CAdES (CMS Advanced Electronic Signatures) format, used for PAdES signatures meeting eIDAS requirements. <code>ETSI.RFC3161</code> — A document timestamp (not an approval signature), using RFC 3161 timestamp protocol.
<strong>Incremental update model</strong> — A PDF signature is always added as an incremental update: new objects (the signature dictionary, the signature annotation widget if visible) are appended to the existing PDF file. The original file body is byte-range signed without modification. This allows multiple signers to add approval signatures sequentially, each signing the file as it existed at their signing time.
Certificate chains and trust
A digital signature is only as trustworthy as the certificate that backs it. X.509 certificates form a chain of trust:
<strong>End-entity certificate</strong> — The signer's certificate, issued by a Certificate Authority (CA). Contains the signer's public key, identity information (Common Name, Organisation), certificate validity period, and extensions identifying permitted uses.
<strong>Intermediate CA certificate(s)</strong> — Typically one or two intermediate CA certificates between the end-entity certificate and the root CA. Intermediate CAs allow the root CA to be kept offline (higher security); intermediate CAs are used for day-to-day certificate issuance.
<strong>Root CA certificate</strong> — The top-level certificate, typically self-signed. PDF viewers have a list of trusted root CAs; a signature is trusted if the certificate chain leads to a root CA that the viewer trusts. Acrobat Reader trusts root CAs in Adobe's Approved Trust List (AATL) and the operating system's certificate store.
<strong>Revocation checking</strong> — Certificates can be revoked before expiry. PDF signature validators check revocation status via OCSP (Online Certificate Status Protocol) or CRL (Certificate Revocation List). For long-term validation, revocation data must be embedded in the signature (LTV — Long-Term Validation). See <a href="/news/pdf-digital-signature-revocation" target="_blank" rel="noopener">PDF Digital Signature Revocation</a> for OCSP, CRL, and LTV details.
<strong>Approval vs certification signatures</strong> — An approval signature attests to document content; multiple parties can add sequential approval signatures. A certification signature (/DocMDP) is the first signature and optionally restricts what changes are permitted to the document after certification — for example, allowing only form field completion and comment annotations.
PAdES and eIDAS legal validity
<strong>PAdES</strong> (PDF Advanced Electronic Signatures, ETSI EN 319 102) defines signature profiles for legally recognised electronic signatures in the EU under the eIDAS Regulation (EU 910/2014):
<strong>Simple Electronic Signature (SES)</strong> — Any electronic data attached to a document (includes email "Regards, Alice"). No certificate required. Minimal legal weight.
<strong>Advanced Electronic Signature (AES)</strong> — Uniquely linked to and capable of identifying the signatory; created using data under the signatory's sole control; detects subsequent changes. An adbe.pkcs7.detached signature from a CA-issued certificate qualifies.
<strong>Qualified Electronic Signature (QES)</strong> — Created with a Qualified Signature Creation Device (QSCD — typically a hardware token or cloud HSM) using a certificate from an EU Trust List Qualified Trust Service Provider (QTSP). QES has the same legal effect as a handwritten signature across the EU. Must use at least PAdES-B-LT profile.
For US contexts, the ESIGN Act (2000) and UETA provide legal recognition for electronic signatures but without the EU's technical tiers — any electronic signature meeting intent and authentication requirements can be legally binding. See <a href="/glossary/electronic-signature" target="_blank" rel="noopener">Electronic Signature</a> for the legal framework comparison.
Frequently asked questions
What is the difference between a digital signature and an electronic signature in PDF?
In PDF, "digital signature" typically refers to a cryptographic PKI-based signature using a signer's certificate — implemented via the PDF signature field mechanism with PKCS#7 or CAdES. "Electronic signature" is a broader legal term covering any electronic indication of intent (a typed name, a drawn image, a checkbox, or a PKI signature). An image of a handwritten signature placed on a PDF page (as a JPEG overlay) is an electronic signature but is not a digital signature — it has no cryptographic properties. The PDF specification supports both via different mechanisms: cryptographic digital signatures via /Sig fields; visual signature images via image XObject overlays. See Electronic Signature for the legal distinction.
Can a PDF have multiple digital signatures?
Yes. Multiple approval signatures are fully supported via incremental updates: each signer appends a new /Sig field and signature dictionary. Each signature covers the byte range of the document as it existed at that signer's signing time. In Acrobat's signature panel, all signatures are listed with their validity status. A certification (DocMDP) signature, if present, must be the first signature and constrains what subsequent signatures can change. A common workflow: author signs with an approval signature; reviewer adds their own approval signature; finally, the authorising manager signs. All three signatures are visible and verifiable in the completed document.
What happens to a PDF signature if the document is edited after signing?
Editing the signed content of a PDF after signing breaks the signature — the cryptographic hash will no longer match, and the signature will display as invalid (typically a red X in Acrobat). This is the integrity protection: any modification to the signed byte ranges is detected. The exception: legitimate incremental updates (adding LTV data, adding subsequent approval signatures, filling in form fields if permitted by the certification signature) are added outside the signed byte ranges and do not break the earlier signature. The signed content is preserved intact; new content is appended. Signature validation checks that incremental updates made after signing do not modify content covered by the signature's /ByteRange.