PAdES, XAdES and JAdES: Signature Formats Explained

Three ETSI standards for different containers

PAdES, XAdES, and JAdES are three digital signature formats defined by ETSI (European Telecommunications Standards Institute). Each is designed for a specific document container: PAdES for PDF, XAdES for XML, and JAdES for JSON. They all implement the same cryptographic principles (PKI, hash, certificate chain) but embed the signature differently depending on the document format.

PAdES vs XAdES vs JAdES

	Format	Best for
PAdES	PDF documents	Human-readable contracts, invoices, certificates
XAdES	XML documents	Structured data, government filings, UBL invoices
JAdES	JSON data	API payloads, DPP data, structured documents

PAdES: signatures inside PDF

PAdES (PDF Advanced Electronic Signature) embeds the digital signature directly into the PDF file.

The signature data — including the certificate, hash, timestamp, and revocation data — is embedded as a PDF object. The PDF reader (Adobe Reader, etc.) can validate the signature natively without external tools.

ETSI defines four conformance levels: B (basic), T (with timestamp), LT (with long-term validation data), and LTA (with archival timestamp). Higher levels ensure the signature remains valid even after the certificate expires.

For any human-readable document that will be viewed in a PDF reader: contracts, invoices, certificates, official letters. PAdES is the most widely supported and user-friendly format.

PAdES signatures can include a visible signature block (the traditional 'signed by' panel in PDFs) as well as the invisible cryptographic signature data. Both are part of the same PAdES signature.

XAdES and JAdES for structured documents

Not all documents are PDFs. Government filings, API responses, and structured data need signature formats designed for their containers.

XAdES for XML

XAdES embeds the signature as an XML element within or alongside the XML document. Widely used in e-government systems (EU member states, LATAM). Supports the same baseline levels (B, T, LT, LTA) as PAdES.

JAdES for JSON

JAdES (JSON Advanced Electronic Signature) applies advanced-signature structures to JSON data and can support enveloped, enveloping, or detached patterns depending on the profile. It is relevant to API and structured-data workflows, but EU DPP rules do not universally mandate JAdES.

CAdES (bonus)

CAdES (CMS Advanced Electronic Signature) is a fourth format for binary data. Less common in practice but used in some PKI infrastructures and for specific regulatory submissions.

Which format should you choose?

Match the format to the document container: PDF → PAdES, XML → XAdES, JSON → JAdES. If you are signing human-readable contracts, PAdES is the right choice. For API-driven data submission (like DPP), JAdES or XAdES is more appropriate.

Signature format specifications: sizes, validation times, and compatibility

Concrete data for choosing between signature formats.

File size impact by format

Signature size depends on certificate chains, timestamps, revocation material, policies, and whether the signature is embedded or detached. Benchmark representative files and profiles rather than using a generic per-format size estimate.

Validation speed

Validation time depends on chain building, revocation endpoints, timestamp checks, file size, network conditions, and the validation library. Run load tests with the intended profile and trust environment before choosing a format for high-volume verification.

Adobe Reader compatibility

PAdES B-B/B-T/B-LT signatures display natively in Adobe Reader with green checkmark. XAdES and JAdES signatures do NOT display in Adobe Reader — they require specialised validation tools. For B2C documents (consumer contracts), PAdES is the only format that non-technical recipients can verify visually.

PAdES levels in practice: B-B, B-T, B-LT, B-LTA compared

Understanding the difference between PAdES baseline levels helps choose the right signing profile.

B-B (Basic): signatures only, no timestamps

PAdES B-B contains the signature and signing certificate but no timestamp or revocation data. Suitable for internal approvals, low-risk NDAs, and documents with short retention needs. Verification fails after certificate expiry. Most basic eSignature platforms produce B-B level signatures by default.

B-T and B-LT: timestamps and revocation data

B-T adds a trusted timestamp, proving the document existed at a specific point in time. B-LT adds certificate revocation data (CRL/OCSP), enabling verification even after the CA goes offline. B-LT is recommended for any contract with a retention period beyond 3 years — which covers most employment, loan, and lease agreements.

B-LTA: archival quality for long-term records

B-LTA can add archival timestamps so validation evidence can be augmented over time. Whether it is required depends on the document, applicable rule, risk assessment, and archival design; confirm the configured eSign.AI profile and re-timestamping process rather than assuming B-LTA is the default.

Common questions

PDF Advanced Electronic Signature. It is the ETSI standard for embedding digital signatures in PDF documents.

How eSign.AI applies this in practice

eSign.AI supports PAdES, XAdES, and JAdES in configured workflows. Select the format from the actual container and receiving-system requirements, then verify the generated signature with an independent validation tool.

Team discussing the right eSignature approach for a business

Explore the right eSignature approach for your business

Talk to our team about eSignature requirements, compliance considerations, and document workflows across your target markets.

Keep reading

Glossary