Validate signature in PDF online, free

Upload the PDF to the checker on this page. It runs in the browser, costs nothing, and returns integrity, certificate chain, revocation status, timestamps and the PAdES profile as separate results. If you'd rather stay in Adobe Acrobat Reader, open the Signatures panel, right-click the signature and choose Validate Signature. Acrobat will tell you whether it's happy, but not which of the four checks it was unhappy about.

Usually not. That message means Acrobat couldn't build a trusted path from the signing certificate up to a root it recognises, which is a trust question rather than a tampering question. A Digital Signature Certificate (DSC) is issued by a Certifying Authority licensed by India's Controller of Certifying Authorities, and that root sits outside both Adobe's own trust store and the EU Trusted List. The usual fix is to import the issuing CA chain and the CCA India root into Acrobat's trusted identities, then revalidate. Chaindoc anchors trust in the EU Trusted List, so a DSC-signed file comes back here with intact cryptography and an unresolved chain. The report keeps those two verdicts apart, which is the bit you actually need in order to know whether the document was altered.

PAdES (PDF Advanced Electronic Signatures) is an ETSI standard for embedding digital signatures in PDF files. It defines four levels of assurance, from basic signatures to long-term archival formats. PAdES signatures are legally recognised under the EU eIDAS regulation as advanced or qualified electronic signatures.

Upload your signed PDF and the EU Digital Signature Service (DSS) library validates it. The check covers four things: cryptographic integrity (the document wasn't modified), certificate validity (the signer's certificate was valid at signing time), timestamp verification, and certificate revocation status via CRL and OCSP. It typically takes a few seconds.

It means four conditions are met: the cryptographic signature is mathematically correct, the document hasn't changed since signing, the signing certificate was valid at that time, and the certificate chain traces back to a trusted root authority. If any of these fail, the signature is marked invalid.

The most common reasons: someone edited the PDF after it was signed, the signing certificate expired or was revoked, the certificate chain can't be traced to a trusted root, or the signature format doesn't comply with PAdES standards. The detailed report shows exactly which validation step failed, so you'll know what went wrong. Not sure this is even a PAdES signature? Chaindoc's signature verification hub detects the format automatically and checks PAdES, XAdES, CAdES and ASiC alike.

Acrobat shows this warning more readily than a strict eIDAS check would, so it doesn't always mean the signature is broken. Three causes cover most cases. Most often, the signing certificate's root isn't in Acrobat's own trust store, and Acrobat checks against its own list of trusted providers, not the EU Trusted List, so a signature can be fully valid under eIDAS and still get flagged here. Less often, the document changed after it was signed. Even a re-save or a flattened form field breaks the signature for real. Occasionally the signing certificate expired and there's no timestamp proving it was still valid at signing time. Acrobat's summary banner doesn't say which of the three applies. Run the same PDF through the checker above and the report names the exact step that failed.

No. Chaindoc processes the PDF for verification only and doesn't keep the file after the check completes. The verification result and signature metadata are retained in your history for audit purposes, but the document content itself isn't stored.

Chaindoc uses the EU Trusted List (EUTL) as the primary trust anchor, which covers all qualified trust service providers under eIDAS. Major commercial CAs (like DigiCert, GlobalSign, and others) are also trusted. If you need to validate signatures from an internal PKI, you can configure custom trust anchors. Check pricing for details on custom trust anchor configuration.

Yes. The tool detects and validates every signature in the PDF separately. The report shows results for each one, including incremental signatures and any modifications made between signing rounds. This is useful for contracts that go through sequential signing workflows where multiple parties sign at different times.

Yes. Each signature format has its own tool. For XAdES signatures in XML files use XAdES verification, for CAdES signatures in .p7m or .p7s files use CAdES verification, and for signed ASiC containers (.asice, .asics) use ASiC container verification. This page verifies PAdES signatures embedded in PDF documents.

Almost always because the reader cannot trace the signing certificate to a root it trusts, not because the document changed. Adobe Acrobat ships its own trusted list and updates it on its own schedule, so a certificate outside that list produces the warning on a file that is perfectly intact. Upload the PDF here and the report separates the two questions: whether the bytes still match the signature, and whether the chain resolves. If integrity passes and only the chain fails, the document is unchanged and what you have is a trust gap.

Not by itself. Tampering fails the integrity check, which is a separate line in the report. A file can pass integrity and still show a warning in your reader because the issuing authority's root is not in that reader's trust store. The two verdicts are kept apart here for exactly this reason, so a trust gap is never mistaken for an altered document.

Upload the file to the checker above. An Aadhaar eSign produces a standard PAdES signature inside the PDF, so the same four checks apply: integrity, the certificate, its chain and the timestamp. You'll see the signer details the eSign provider embedded, the issuing CA, and the moment the signature was made. Nothing needs installing, and you don't need the signer's cooperation to run it.

Yes, as long as a timestamp was embedded, and eSign providers do embed one. Validation asks whether the certificate was live at the moment of signing, not whether it's live now. That's why the PAdES-T profile matters more for eSign than for a multi-year DSC.