How to verify a digital signature in a pdf
- Step 1Open the verifier and drop your signed PDF — Load the document into the PDF Signature Verifier. Parsing and verification happen entirely in your browser — nothing is uploaded.
- Step 2Optionally add trust anchors — To check the signer's certificate chain, paste a PEM bundle of the root (and any intermediate) certificates you trust. Without anchors, the tool still checks integrity and document coverage and notes that no anchors were supplied.
- Step 3Read the per-signature verdict — For each signature you get: intact (digest + signature verify), covers-whole-document (no bytes added after signing), chain-trusted (when anchors are given), the signer's common name, signing time, and the digest + signature algorithms.
- Step 4Download the JSON report — Save the full machine-readable report to attach to an audit trail or share with a counterparty.
What each verdict field means
Every signed PDF is reported signature-by-signature; a document can carry more than one.
| Field | Meaning | When it's false |
|---|---|---|
intact | The ByteRange digest matches and the PKCS#7/CMS signature verifies against the signer certificate. | A byte inside the signed range was changed — the document was tampered with. |
coversWholeDoc | The signature's ByteRange reaches the end of the file. | Bytes were appended after signing (a later revision, or an added page/annotation). |
chainTrusted | The signer's certificate chains to one of your trust anchors and was within its validity window at signing time. | The issuer isn't in your anchor set, or the certificate was expired — or the signature isn't intact (trust is not asserted on a broken signature). |
signerCommonName | The CN pulled from the signer's certificate subject. | The certificate omits a common name. |
How PDF signature verification actually works
The same pipeline every conformant verifier runs, including this tool.
| Step | What happens |
|---|---|
| 1. Locate the signature | Read the signature dictionary's /ByteRange [a b c d] — the two byte spans that were signed — and the /Contents <…> hex blob holding the PKCS#7/CMS structure. The gap between the spans is exactly where /Contents sits, so the signature can never sign itself. |
| 2. Recompute the digest | Concatenate the two ByteRange spans and hash them with the algorithm named in the CMS (e.g. SHA-256). This is the document's actual digest. |
| 3. Verify the CMS signature | Check the recomputed digest against the signed messageDigest attribute, then verify the CMS signature over those attributes using the signer certificate's public key (RSA or ECDSA). |
| 4. Validate the chain | Build a path from the signer certificate through any embedded intermediates to a trusted root, checking validity dates. (Live OCSP/CRL revocation is out of scope here — see the FAQ.) |
Supported algorithms
| Category | Supported |
|---|---|
| Signature | RSA (PKCS#1 v1.5), ECDSA (P-256, P-384) |
| Digest | SHA-256, SHA-384, SHA-512 (SHA-1 parsed for legacy, flagged weak) |
| Signature type | adbe.pkcs7.detached and ETSI.CAdES.detached (PAdES) |
| Multiple signatures | Yes — each is verified independently with its own coverage |
Cookbook
Common verification scenarios and exactly what the tool reports for each.
A valid, untampered signature
The expected result for a correctly signed, unmodified document.
intact: true coversWholeDoc: true chainTrusted: true (when you supply the signer's root) signer: "Alice Example, Acme Ltd" digestAlgorithm: SHA-256
A document edited after signing
Someone changed a number in the contract after it was signed. The digest no longer matches.
intact: false ← tampering detected coversWholeDoc: true chainTrusted: false (trust is not asserted on a broken signature) notes: "CMS signature did not verify against ByteRange digest"
Extra pages appended after signing
The original signature is genuine, but content was added after it — common with incremental saves. The signature is intact but no longer covers the whole file.
intact: true coversWholeDoc: false ← bytes added after this signature notes: "signed ByteRange does not reach end of file"
Verifying with your own trust anchors
Paste a PEM bundle (root + intermediates) to turn on chain validation. Without it, integrity and coverage are still checked.
-----BEGIN CERTIFICATE----- MIIB... (your trusted root) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIB... (issuing intermediate) -----END CERTIFICATE-----
Edge cases and what actually happens
The PDF has no digital signature at all
0 signaturesThe tool reports zero signatures and says so plainly. A visible 'signature' image drawn on the page (see PDF Sign) is not a cryptographic signature and won't be detected here.
Signature is intact but the certificate is expired
not trustedIntegrity passes (intact: true) but chain validation fails because the certificate was outside its validity window. Many signers use a trusted timestamp to prove they signed while the cert was valid; timestamp-based long-term validation is not evaluated by this tool.
Self-signed or unknown issuer
not trustedIf the signer's root isn't in the anchors you provide, the chain can't be built and chainTrusted is false — even though the signature itself may be perfectly intact. Supply the correct root PEM to validate it.
Multiple signatures, one added later
per-signatureEach signature is verified independently. Earlier signatures legitimately don't cover the bytes added by later signatures, so a non-final signature showing coversWholeDoc: false is normal — not evidence of tampering.
Encrypted / password-protected PDF
limitedSignature bytes are still readable for verification, but unlock the document first (see PDF Unlock) if parsing fails on a strongly encrypted file.
Signature uses an unsupported algorithm
reportedIf the CMS uses an algorithm outside the supported RSA/ECDSA + SHA-2 set, the tool reports the algorithm name and that it could not verify, rather than silently passing.
You need OCSP/CRL revocation or PAdES-LTA
out of scopeThis tool does not perform live revocation lookups or long-term-validation checks. For those, use a desktop verifier such as Adobe Acrobat (Reader shows a signature panel) or the open-source pyHanko.
Frequently asked questions
What does it actually mean to "verify" a PDF signature?
Three independent checks. Integrity: recompute the digest over the signed /ByteRange and verify the PKCS#7/CMS signature against the signer's certificate — this proves the signed bytes weren't altered. Coverage: confirm the signature reaches the end of the file, so nothing was appended afterward. Trust: build the certificate chain to a root you trust, within its validity window. This tool does all three (trust requires you to supply anchors).
Will it tell me if a document was changed after it was signed?
Yes — in two ways. If a byte inside the signed region was changed, the digest no longer matches and the signature is reported as not intact (tampering). If bytes were added after the signature (a later revision or an extra page), the signature stays intact but is flagged as not covering the whole document. Both are surfaced clearly.
Does it check certificate revocation (OCSP/CRL)?
No. This version validates the certificate chain and validity dates but does not perform live OCSP or CRL revocation lookups, and does not evaluate long-term-validation (PAdES B-LT/B-LTA). For full revocation and LTV checking, use Adobe Acrobat or the open-source pyHanko. Everything else — integrity, coverage, chain, RSA/ECDSA, multi-signature — is verified here.
Is my signed document uploaded anywhere?
No. Parsing and all cryptographic verification run entirely in your browser using the Web Crypto API. The document never leaves your device; only anonymous usage counters are recorded when you're signed in.
What signature algorithms are supported?
RSA (PKCS#1 v1.5) and ECDSA (P-256 and P-384), with SHA-256, SHA-384, and SHA-512 digests. SHA-1 is parsed for legacy documents but flagged as weak. Both adbe.pkcs7.detached and the PAdES ETSI.CAdES.detached subfilter are handled.
What is the ByteRange, and why does it matter?
The /ByteRange [a b c d] array names the two spans of the file the signature covers — everything except the gap holding the signature itself (/Contents). A verifier hashes exactly those spans. Because the signature can't cover its own bytes, the only safe way to confirm nothing else changed is to also check that the second span reaches end-of-file — which is the coverage check this tool performs.
How do I check who signed it and whether I trust them?
The report shows the signer's common name and signing time from the certificate. To verify trust cryptographically rather than just reading a name, paste a PEM bundle of the root (and intermediate) certificates you trust; the tool then validates that the signer's certificate chains to one of them within its validity window.
It says the signature is intact but "not trusted" — what does that mean?
The cryptography is sound — the bytes weren't altered — but the signer's certificate didn't chain to a root in your trust anchors (or you didn't supply any). That's expected for self-signed certificates or signers whose CA you haven't added. Supply the correct root PEM to establish trust.
Can it verify a document with several signatures?
Yes. Each signature is verified independently and reported on its own row, with its own integrity, coverage, and trust result. Note that earlier signatures in a multi-signature document legitimately do not cover bytes added by later signatures.
Does a hand-drawn or image signature count?
No. A picture of a signature placed on a page (what the PDF Sign tool produces) carries no cryptographic proof and isn't detected here. This tool verifies real digital signatures embedded as PKCS#7/CMS data.
How is this different from the PDF Digital Signature viewer?
The PDF Digital Signature viewer reads and displays signature metadata (who, when, why) without cryptographic verification. This tool actually verifies the signature — digest, CMS, coverage, and chain. Use the viewer for a quick look; use the verifier to confirm validity.
What can I do with the JSON report?
It's a machine-readable record of every signature's verdict (intact, coverage, trust, signer, algorithms, notes). Attach it to an audit trail, feed it into a compliance workflow, or share it with a counterparty as evidence of the checks you ran.
Is browser-based verification as reliable as a desktop tool?
For integrity, coverage, and chain validation, yes — the cryptography uses the same standards (PKCS#7/CMS, X.509) and the Web Crypto API. The gap versus a full desktop verifier is live revocation (OCSP/CRL) and PAdES long-term validation, which this tool intentionally leaves to dedicated software like Acrobat or pyHanko.
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.