If you have opened a signed PDF and seen a PAdES level such as B-T or B-LT in its properties, or a customer’s compliance team has asked which PAdES level your documents carry, this is the answer: what the standard is, what the four levels each add, what the timestamp contributes and how to check any of it yourself.
PAdES, in one sentence
PAdES stands for PDF Advanced Electronic Signatures: the rules for how a digital signature is built into a PDF file. Despite the name, the format alone does not make a signature “advanced” in the legal sense; that is a separate test, under Article 26 of UK eIDAS. The rules are published by ETSI as EN 319 142-1 (PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures, version 1.2.1, January 2024), with further profiles in EN 319 142-2.
It belongs to a family. CAdES (EN 319 122) covers signatures over arbitrary data in CMS format, XAdES (EN 319 132) covers XML, and ASiC (EN 319 162) covers signed containers. PAdES is the PDF one, and it sits on machinery already in the PDF specification: ISO 32000-1 defines the signature dictionary a PDF can carry, and PAdES specifies what must go in it.
So PAdES is not a file format, a product or a vendor. It is a profile (which cryptographic attributes must be present, where and in what form), so a signature applied by one piece of software can be verified by different software years later, by somebody who has never heard of the company that made it.
A signature in the file, not a picture on the page
Most “signed” PDFs in circulation are not signed in any technical sense. Somebody has pasted an image of a squiggle onto a page and saved the file. That image is ordinary page content: no key, no hash, no link to the rest of the document. It can be cut out and dropped onto a different contract in a minute, the page around it can be edited freely, and no PDF reader will object, because nothing unusual has happened to the file.
A PAdES signature is a different object. At signing, the software takes a digest (SHA-256 or SHA-384, for example) over the bytes of the file, signs it with a private key, and writes the result into the PDF as a DER-encoded CMS SignedData object, the structure in IETF RFC 5652. Three entries in the signature dictionary carry it:
- Contents: the signature itself, the CMS object.
- ByteRange: exactly which bytes of the file it covers.
- SubFilter: the value ETSI.CAdES.detached for a PAdES signature, or ETSI.RFC3161 for a PAdES document timestamp such as Pixasign’s seal, which is what marks it as PAdES rather than an older PDF signature encoding.
Change one byte inside the covered range and the digest no longer matches, so the signature fails. The squiggle you see on a properly signed PDF is a signature appearance: decoration for human readers. The evidence is the CMS object, and it would work just as well with nothing drawn on the page at all.
The four baseline levels: B-B, B-T, B-LT and B-LTA
Clause 6.1 of EN 319 142-1 defines four levels, each building on the one before, because a signature has a life cycle: what proves a document today is not what proves it once the certificates have expired and the algorithms have aged.
| Level | What it adds | What that buys you |
|---|---|---|
| B-B | The signature and its signed attributes, at the moment of signing | Who signed, and that nothing has changed since, but no independent evidence of when |
| B-T | A trusted token proving the signature existed at a certain date and time | An independent party attests the time, so the signer cannot move it |
| B-LT | All the material needed to validate the signature, embedded in the document | Checkable offline, years later, without fetching anything |
| B-LTA | Further document timestamps applied over that whole structure | Survives certificate expiry and ageing algorithms; the archival level |
The “material” B-LT adds means the full certificate chain plus revocation data (a revocation list or an OCSP response for every certificate in it), stored in a Document Security Store dictionary inside the PDF. B-LTA then time-stamps that structure, repeatedly if necessary, so protection can be extended indefinitely.
Pixasign seals each finished document with a PAdES document timestamp, the kind of timestamp B-LTA is built from, issued by DigiCert over the whole file and signed with RSA-4096 and SHA-384. The validation material B-LT describes is embedded alongside it, so the file carries what a validator needs to check the seal later.
What an RFC 3161 timestamp adds
The trusted token that turns B-B into B-T is a timestamp, specified by IETF RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol, August 2001, updated by RFC 5816.
The mechanism is deliberately narrow. The signing software sends a hash of the signature to a timestamp authority (TSA). The authority never sees the document. It only ever receives a digest. It takes its own reading from a trustworthy clock, signs the hash and the time together with its own key, and returns a TimeStampToken that is embedded in the PDF. What comes back is proof of existence: this exact signature existed no later than that moment.
The value of it turns entirely on who issued it. A timestamp from the same organisation that made the signature proves far less about time to anybody else, because one party controlled both the signature and the clock, and a competent opponent will say exactly that. Independent attestation by a trusted third party is the reason RFC 3161 exists. Pixasign’s seal is itself a timestamp from DigiCert, an independent timestamp authority, and the hash sent to DigiCert is of the whole finished document rather than of a signature. The time of each earlier step is recorded by our server on the evidence certificate. If sealing cannot reach DigiCert the seal fails, rather than quietly falling back to something weaker.
“Covers the whole file”, and the trick that defeats it
Requirement k of clause 6.3 is short and load-bearing: “The ByteRange shall cover the entire file, including the Signature Dictionary but excluding the PDF Signature itself.” At the moment of signing, everything is inside the covered range.
The problem arrives afterwards. A PDF can be updated incrementally: new objects appended to the end of the file, earlier bytes never touched. That is a specified feature: it is how a second person countersigns a contract. It also means a revision can be appended that overlays new text on an already-sealed page while the signed bytes stay intact. The maths still checks out, the certificate still chains, and the document now says something it did not say when it was signed. Stamp “PAID IN FULL” across a sealed quotation that way, and a validator that checks only integrity reports intact, valid and trusted: every answer correct in isolation, and the verdict assembled from them completely wrong.
Our free public checker recognises the exact files Pixasign sealed, from our own records, and tells you if one has changed since it was sealed, so an appended revision, or a lookalike made somewhere else, can never be mistaken for ours.
How to check a PAdES signature yourself
The first two need nothing from us, which is the point of using a published standard.
- pdfsig, part of the open-source poppler-utils package: signer, signing time, hash algorithm, signature type, the signed byte ranges and whether they cover the whole document.
- pyHanko, an open-source Python library for signing and validating PDFs, with a command-line validator that reports coverage explicitly. It is independent of Pixasign, and it is what we use internally.
- Our free public checker, for files Pixasign sealed: it confirms the file is one we sealed and whether it has changed since. No account, no login, nothing to install.
See one for yourself
The quickest way to understand any of this is to look at a real sealed PDF and the evidence certificate that comes with it. Check a document you already have, without an account, or send one of your own. If you have none to hand, download a real sealed PDF: a made-up quotation, sealed by Pixasign with a DigiCert document timestamp, ready to drop on the check page.
Check a signed document UK company. Documents stored in the EEA, with the seal and timestamp inside the PDF itself.Questions
- What is the difference between the B-T and B-LT levels of PAdES?
- B-T adds a trusted timestamp token proving the signature existed at a particular date and time. B-LT goes further and embeds inside the PDF everything a validator needs to check the signature later without going online: the certificate chain plus revocation data such as a revocation list or an OCSP response for each certificate. The difference is longevity. B-T stays checkable for as long as a validator can obtain and trust the chain; B-LT carries its own proof with it, and B-LTA time-stamps that material so it survives certificate expiry and ageing algorithms.
- Can a PAdES signature be checked without the company that created it?
- Yes, and that is the main argument for a published standard over a proprietary one. The signature, the certificate chain and the timestamp token all live inside the PDF, and open-source validators such as pdfsig from poppler-utils and pyHanko can each check that the file is intact and when it was time-stamped. Whether a file is one Pixasign sealed is answered free at pixasign.co.uk/check. Evidence that only works while you keep paying a supplier is not evidence you control.
- Does a PAdES signature stop someone editing the PDF?
- No, and it is worth being precise. Nothing stops a person opening a file and changing it, or appending a revision to the end of it. What the signature does is make the change detectable: edit the signed bytes and verification fails outright; append a revision instead and a competent validator reports that the signature no longer covers the whole file. Detection rather than prevention is what the standard offers, which is why a result that reports only whether the signature is intact is not enough.