eSign.AIeSign.AI

Solution Guides

Choosing PAdES, XAdES or JAdES for Document Signing

PAdES for PDF, XAdES for XML, JAdES for JSON. Each signature format has specific use cases. Here is how to choose.

eSign.AI Solutions Team6 min read

Signature formats are not interchangeable

PAdES, XAdES and JAdES are ETSI standards for advanced electronic signatures, each designed for a specific document container. Choosing the wrong format means the signature may not embed properly, may not validate in standard tools, or may not achieve long-term validation requirements. Most signing platforms default to one format — usually PAdES for PDF — but enterprise workflows often need to support multiple formats.

PAdES vs XAdES vs JAdES at a glance

Document typeETSI standard
PAdESPDF documentsETSI EN 319 142
XAdESXML documents, SOAP, structured dataETSI EN 319 132
JAdESJSON documents, REST API payloadsETSI TS 119 182

When to use each format

The document format determines the signature format. Here are the typical scenarios for each.

01

PAdES (PDF Advanced Electronic Signature) embeds the signature directly into the PDF file. The signed PDF is self-contained: the document, signature, certificate, and validation material travel together. This is the most widely used format for commercial contracts, employment agreements, and official documents.

02

XAdES (XML Advanced Electronic Signature) wraps the signature in XML structure. It is used in government filings (EU member states' e-government services), B2B messaging (SOAP web services), and structured document workflows where XML is the native format.

03

JAdES (JSON Advanced Electronic Signature) is the newest standard, designed for JSON document signing in API-driven workflows. It is used for signing API responses, smart contract data, and JSON-structured records that require legal evidence.

Why long-term validation (LTV) matters regardless of format

All three formats support Baseline Levels (B, T, LT, LTA). Higher levels add material needed to validate the signature after the signing certificate expires.

Level B (Basic)

The signature and certificate are embedded. Sufficient for short-term validation. Cannot be verified after the certificate expires.

Level T (Timestamp)

Adds a trusted timestamp from a Time Stamping Authority (TSA). Proves the signature existed at a specific time, even after certificate expiry.

Level LT (Long-Term)

Adds validation material (certificates, CRLs, OCSP responses) needed to re-validate the signature. The signature can be verified years later without accessing external sources.

Level LTA (Long-Term Archive)

Adds archival timestamps that periodically re-confirm the validity of previous timestamps. Used for records that must remain provable for decades (e.g. land records, government archives).

If your document is...

  • PDF (contract, letter, form) → PAdES
  • XML (government filing, B2B message) → XAdES
  • JSON (API payload, data record) → JAdES
  • Multiple formats in one workflow → support all three

Choose LTV level by retention need

  • Short-term (< 2 years) → Level B or T
  • Medium-term (2-10 years) → Level LT
  • Long-term (10+ years) → Level LTA
  • Regulated/archival → Level LTA with TSA timestamps

How eSign.AI handles signature formats

eSign.AI supports configurable signature-format selection based on the document container and workflow requirements. Confirm the enabled formats and baseline profiles for the selected deployment.

PAdES for PDF signing

For PDF workflows, configure the required PAdES baseline profile after assessing retention and validation needs. Where LT or LTA evidence is required, verify timestamping, revocation-data capture, and any re-timestamping process with sample files.

XAdES for XML and regulatory filings

For XML workflows, eSign.AI can support a configured XAdES profile. Compatibility must be tested against the receiving authority's schema, signature policy, certificate requirements, and validation service.

Signature format selection by jurisdiction and use case

Which format to choose depends on the regulatory environment and document type.

EU: PAdES for PDF, XAdES for XML data

Under eIDAS, PAdES is the default for PDF documents because Adobe Reader natively validates PAdES signatures with a green checkmark. XAdES is used for structured data (eInvoicing, regulatory filings). The EU eInvoicing Directive 2014/55/EU requires XAdES (or PAdES/CAdES) for B2G invoices. JAdES is newer and not yet widely adopted in EU regulatory frameworks.

APAC: PAdES dominance, emerging XAdES

In APAC markets, PDF-based contracts commonly use PAdES, while structured regulatory or enterprise exchanges may require XML or another container. Singapore's ETA and Hong Kong's ETO do not generally mandate PAdES, XAdES, or JAdES. Confirm the receiving system's technical profile instead of inferring it from jurisdiction alone.

When to use LTV (Long-Term Validation)

Consider an LT or LTA profile when the evidence must remain verifiable beyond the period in which certificate and revocation data are readily available. Retention periods differ by jurisdiction and document type; confirm both the legal retention rule and the platform's configured validation profile.

Frequently asked questions

PAdES. It is the ETSI standard for PDF signatures and is supported by Adobe Reader, Foxit, and other PDF viewers. Use Level LT or LTA for contracts that need long-term enforceability.

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.