Verify the digital signatures in a PDF — on your device
Digest, signature, certificate, coverage and timestamp, checked locally with a downloadable report.
Free: 3 jobs per UTC day, 25 MB per file. PDF exports include a visible Made with Bindery watermark. Pro exports clean PDFs.
Prefer the full studio? Open Verify PDF signature in the app →
Drop a signed PDF and Bindery reads every signature dictionary, recomputes the digest over the signed byte range, verifies the CMS signature against the embedded certificate (RSA PKCS#1, RSA-PSS or ECDSA, SHA-1 to SHA-512), reads the signer’s name, organisation, issuer and validity dates, and checks whether the signature covers the whole file or an earlier revision that was changed afterwards.
It also decodes RFC 3161 timestamp tokens and confirms they belong to the signature. What it deliberately does not do is claim trust: with no certificate-authority store in the browser it tells you who issued the certificate and whether it is self-signed, and leaves the trust decision where it belongs. Bindery runs entirely in your browser — your file is never uploaded, so there is nothing to delete from a server afterwards.
How it works
- Drop the signed PDF and open Verify signatures
- Every signature is checked on your device in a second or two
- Read the per-signature results or download the report
What verification actually checks
A signed PDF carries one or more signature dictionaries. For each, Bindery recomputes the digest over the signed byte range, verifies the CMS signature against the embedded certificate — RSA PKCS#1, RSA-PSS or ECDSA, with SHA-1 through SHA-512 — reads the signer’s name, organisation, issuer and validity dates, and checks whether the signature covers the whole file or only an earlier revision. RFC 3161 timestamp tokens are decoded and matched to their signature. The result is per signature, in plain language, with a downloadable report.
- Contracts returned by e-signature services — see who signed what, and whether anything was changed afterwards.
- Government and court documents with official signatures.
- Your own certified files, before you send them.
Trust is a separate question, and Bindery says so
Integrity can be proved from the file alone. Trust in the identity requires a chain to a certificate authority, and a browser has no such store and Bindery never contacts one. So the tool tells you who issued the certificate, whether it is self-signed, and whether the signature covers the current revision — and leaves the trust decision to you or your organisation’s reader, which is where it belongs. A valid signature “not chain-validated” means exactly that: intact, issuer shown, identity not vouched for here.
Verifying in the browser versus uploading
| Verify signatures | Bindery | Upload-based tools |
|---|---|---|
| Where the file is processed | In your browser tab, on your device | Uploaded to the service’s servers |
| The signed document | Read on the device; nothing transmitted | Uploaded, retained for a period |
| Detail | Digest, algorithm, certificate, coverage, timestamp, per signature | Often a single pass/fail |
| What exists afterwards | The original and the new file, both on your device | A server copy until the retention window ends |
| Works offline | Yes, once the app has loaded | No |
Questions people ask
What does “covers an earlier revision” mean?
PDF signatures protect a byte range. If a form was filled, a comment added or a second signature applied after signing, the file grew and this signature covers only the earlier revision — the report says so instead of calling the file “modified” or “fine”.
Why is a valid signature shown as “not chain-validated”?
Bindery has no list of trusted certificate authorities and never contacts one. It proves the file is intact and shows the issuer; whether you trust that issuer is a decision your reader or organisation makes.
Which signature types are supported?
adbe.pkcs7.detached, ETSI.CAdES.detached and adbe.pkcs7.sha1 (the CMS-based types nearly every tool writes), with RSA, RSA-PSS and ECDSA P-256/P-384 keys. Older adbe.x509.rsa_sha1 signatures are reported as unsupported.
What does “signature covers an earlier revision” mean?
A PDF signature protects a byte range. If a form was filled, a comment added or another signature applied after signing, the file grew and this signature covers only the earlier revision. It is not necessarily tampering — a second signature does exactly this — but the report shows it instead of calling the file “fine” or “modified”.
Why is a signature reported as unsupported?
Older adbe.x509.rsa_sha1 signatures use a format outside the CMS types nearly every current tool writes. The report says so rather than guessing.
Is the report evidence I can share?
It is a plain-language record of what was checked and found, produced on your device. It is useful documentation; formal evidentiary weight depends on your context.