Verify a PDF signature
Open a digitally signed PDF to check it against the 8‑point verification model. The document is read in this tab and is never uploaded.
What gets checked
- Integrity
- Signature
- Chain
- Identity
- Timestamp
- Revocation
- Algorithm
- EKU
What this tool does
Drop a digitally signed PDF above and it is checked the way Adobe Reader checks one: the document is re-hashed and compared against the signature, the signer's certificate is followed up to a trusted root, and eight independent checks are reported separately rather than collapsed into a single tick.
Reporting them separately is the point. “Invalid” on its own tells you almost nothing — a document whose bytes were altered after signing and a document signed with a perfectly sound certificate that no public authority vouches for both fail, and they are not remotely the same problem. Each check below says what it tested and what a failure there actually means.
The eight checks
Each one runs independently and reports its own status, so a failure points at a specific thing rather than at the document as a whole.
Integrity
Re-hashes the byte ranges the signature covers and compares the result against the hash sealed inside it. This is the check that catches edits: if it fails, the bytes changed after signing.
Signature
Tests the signature value against the public key in the signer's certificate. A failure means the signature was not produced by the private key belonging to that certificate.
Certificate chain
Follows the signer's certificate up to a root in the built-in Adobe Approved Trust List — the same root set Adobe Reader trusts by default. An untrusted chain does not mean the signature is forged; it means no authority you trust vouches for who the signer is.
Signer identity
Checks each certificate in the chain was inside its validity window at the moment of signing, not at the moment you opened the file. A signature made with a certificate that has since expired stays valid.
Timestamp
Looks for an RFC 3161 token from a timestamping authority and verifies it. Without one, the signing time is only what the signer's own clock claimed it was, and nothing independent supports it.
Revocation
Asks whether the certificate was withdrawn before it expired — key lost, key compromised, holder left the organisation. Revocation data embedded in the PDF is read first; live CRL and OCSP lookups happen only with the revocation plugin enabled.
Algorithm
Reports the hash and key algorithms used and flags weak ones. SHA-1 signatures are reported rather than rejected, which is what Adobe Reader does too — rejecting them outright would fail a large number of otherwise sound older documents.
Key usage
Confirms the certificate's Extended Key Usage extension actually permits document signing. A certificate issued for TLS and then used to sign a PDF fails here even when every other check passes.
What leaves your browser
Your PDF does not. It is read with the browser's File API and parsed by a WebAssembly module running in this tab. There is no upload step, and no copy of the document on any server. This is worth checking rather than taking on trust: open your browser's network panel before you drop a file in, and you will see no request carrying it.
One thing does go out, and only while the revocation plugin is enabled — it is on by default, and the switch is under Settings → Verify. Asking whether a signing certificate was revoked means asking the authority that issued it, and browsers cannot reach most CRL and OCSP endpoints directly because those servers send no CORS headers. The request is therefore relayed through an endpoint on this site, and it carries the signer's certificate — subject name, issuer, serial number — rather than the document.
Turn the plugin off and nothing leaves the tab at all. Revocation then falls back to whatever is already embedded in the PDF, which is exactly what PAdES B-LT and B-LTA signatures carry that data for: they are built to stay verifiable years later with no network at all.
What it will not tell you
A verified signature is a narrow claim, and it is worth being clear about its edges. It says the document has not changed since it was signed, and that it was signed by the holder of a particular private key. It says nothing about whether the contents are true, whether the signer was entitled to sign, or whether the agreement is enforceable where you live.
It also cannot find a signature that was never there. A scanned image of handwriting, or a name typed in by an e-signing workflow, leaves no cryptography behind — there is nothing to check, and the document will simply report no signatures.
Signature types that are recognised: adbe.pkcs7.detached, legacy adbe.pkcs7.sha1, ETSI.CAdES.detached, and ETSI.RFC3161 document timestamps, including DocMDP certification signatures and the PAdES long-term profiles.
Questions
Is my PDF uploaded anywhere?+
No. The file is read through the browser's File API and parsed inside a WebAssembly module in this tab. There is no upload step and no copy on any server. Open your browser's network panel before you drop a file in and you can watch that for yourself — no request carries the document.
Then what is the revocation request I can see in the network panel?+
That is the one thing that does leave the tab, and only while the revocation plugin is on. Checking whether a certificate was revoked means asking the authority that issued it, and browsers cannot call most CRL and OCSP endpoints directly because those servers send no CORS headers — so the request is relayed through an endpoint on this site. It carries the signer's certificate, not the document. Turn the plugin off in Settings and nothing leaves at all.
Why does it say the signature is valid but the certificate is not trusted?+
Those are two different questions. The signature being valid means the document has not changed since it was signed. Trust means an authority in the trust list vouches for who the signer is. A self-signed or private-CA certificate can produce a perfectly valid signature that nothing in the Adobe list will vouch for — common for internal company documents, and not by itself a sign of anything wrong.
My document has a signature on it but nothing is detected.+
A picture of a signature is not a digital signature. Scanned handwriting, a drawn squiggle, or a typed name added by an e-signing workflow carries no cryptography, so there is nothing to verify — this tool will open the document and report no signatures. A real digital signature is embedded in the PDF structure and is what Adobe Reader shows in its signature panel.
Does it agree with Adobe Reader?+
That is the intent. The eight checks mirror Adobe Reader DC's default behaviour, the same AATL root store is built in, and PAdES B-B, B-T, B-LT and B-LTA are all detected. Where the two can differ is trust configuration: Reader also honours roots your operating system or your organisation has added, and those are not in the list here.
Can I use this in my own application?+
This page is free to try and needs no account. The SDK behind it is a commercial product licensed per project — the same engine, as npm packages for the browser and for Node.js. The documentation is open to read, and the pricing page covers how to get access.
The same engine, in your own application
This page is a demonstration of the VerifyKit SDK — a commercial, licensed library that runs the verification pipeline above in the browser and on Node.js. Trying it here is free and needs no account; using it in a product does not.