PAdES
ETSI standard for electronic signatures in PDF documents — embeds the signature directly in the PDF, supports long-term validation and is eIDAS-compliant.
Also known as: PDF Advanced Electronic Signatures, ETSI EN 319 142, PAdES-BES, PAdES-LTV
Short definition
PAdES (PDF Advanced Electronic Signatures) is the standard for electronic signatures in PDF documents, published by ETSI as EN 319 142. Unlike an external signature file (CAdES or XAdES), a PAdES signature is embedded directly into the PDF — it becomes part of the document and travels with it.
PAdES is one of the signature formats recognised under the eIDAS regulation (EU 910/2014), giving it legal standing across the entire EU.
Profiles
PAdES defines four validation profiles that build on each other in increasing long-term robustness:
| Profile | Short name | Contains | Typical use |
|---|---|---|---|
| Basic | PAdES-B-B | signature + certificate | short-lived signatures |
| With Timestamp | PAdES-B-T | + timestamp | documented signing time |
| Long-Term Validation | PAdES-B-LT | + validation data (OCSP/CRL) | decades-long verifiability |
| Long-Term with Archive TS | PAdES-B-LTA | + archive timestamp | audit-safe archiving |
For invoices, contracts and official documents, PAdES-B-LT or PAdES-B-LTA is usually the right choice — they remain verifiable even after the signing certificate has expired.
PAdES, CAdES and XAdES
All three are ETSI Advanced Electronic Signature formats, but for different containers:
- PAdES — signature inside PDF
- CAdES — signature in binary files (ETSI counterpart to CMS/PKCS#7)
- XAdES — signature in XML (e.g. for signing XRechnung)
Relevant for digital invoices: ZUGFeRD PDFs are typically signed with PAdES, pure XRechnung XML with XAdES when signing is required.
What it contains technically
A PAdES signature consists of a ByteRange (which part of the PDF was signed), a PKCS#7 structure carrying the actual signature and — depending on the profile — embedded timestamps and OCSP/CRL responses. These validation artefacts live in a DSS (Document Security Store), a dedicated PDF object defined by PAdES.
The signature block does not modify the PDF retroactively: it is appended as an incremental update, leaving the original bytes intact and verifiable.
Signing with the Dokmatiq API
curl -X POST https://api.dokmatiq.com/v1/pdf/sign \
-H "Authorization: Bearer $DOKMATIQ_KEY" \
-F "document=@invoice.pdf" \
-F "certificate=@signing.p12" \
-F "passphrase=..." \
-F "profile=PAdES-B-LT" \
-F "reason=Invoice 2026-0042" \
-F "location=Munich" \
-o signed.pdf
When needed, the API fetches OCSP and CRL responses automatically and embeds them — the result is a PDF that is long-term validatable out of the box. Timestamps are pulled from a configured qualified TSA (Time Stamping Authority).
Verifying a signature
curl -X POST https://api.dokmatiq.com/v1/pdf/sign/verify \
-H "Authorization: Bearer $DOKMATIQ_KEY" \
--data-binary "@signed.pdf"
Response: profile, certificate chain, trust anchor (EU Trusted List for eIDAS), timestamp status and any modifications made after signing.
Common pitfalls
- Wrong profile — PAdES-B-B is not enough for GoBD-compliant archiving; use at least PAdES-B-LT
- Expired certificate — without long-term validation the signature is no longer checkable once the certificate expires (even if the signing time was valid)
- Changes after signing — any modification invalidates the ByteRange; later annotations require a new signature layer
- Certificate not in the EU-TL — for qualified signatures the issuer must be listed in the EU Trusted List
Ready to use it via API?
Get started for free. No credit card. 100 documents per month included.