How to Choose a PDF Signature Verification SDK

Most "PDF SDK" comparisons are really document-platform comparisons: editing, forms, redaction, OCR, conversion. This one is narrower. It asks a single question — when a signed PDF arrives, what does each option actually tell you about it? — and answers it from vendor documentation and source, not from feature-grid marketing.

If you need to sign, edit or redact, skip to the last section: VerifyKit does none of those, and two of the options below do all of them.

The eight questions a verifier has to answer

Any honest verification result has to answer these separately, because a document can pass any subset of them:

1. Integrity — do the bytes still hash to what was signed?
2. Signature — does the PKCS#7/CMS signature verify against the signer's public key?
3. Chain — does the signing certificate chain to a root, cryptographically, not just by issuer name?
4. Trust — is that root one you accept (AATL, EUTL, a national CCA, your own)?
5. Expiry — was the certificate valid at signing time, and is it still valid now? Those are different questions.
6. Timestamp — is there an RFC 3161 token proving when the signing happened, and does the TSA's own chain verify?
7. Revocation — was the certificate revoked, and was it revoked before or after the signature was made?
8. Algorithm and key usage — was it signed with something still considered sound, using a certificate whose extended key usage permits document signing?

The reason to enumerate them is that collapsing them loses information a user needs. "Invalid" and "the certificate expired in 2024 with no timestamp to prove when it was signed" are the same verdict and completely different messages.

Point 7 is where most tools quietly stop. A certificate revoked after a properly timestamped signature does not invalidate that signature — treating revocation as one boolean gets real documents wrong.

The four categories

1. Open-source JavaScript libraries

pdf-lib, @signpdf, PDF.js, the verify-pdf family, PKI.js, node-forge.

What you get: integrity and PKCS#7 verification, sometimes. @qlever-llc/verify-pdf v3 does cryptographic chain verification; the older packages check issuer names only. PKI.js and node-forge give you primitives, not a verdict.

Where they stop: none of them ship a document-signing trust store, none check revocation, none classify PAdES levels. They are answering questions 1–3 and leaving 4–8 to you.

Cost: free, and the integration is an afternoon. Building 4–8 on top is not an afternoon — it is a trust list you have to source and keep current, an OCSP/CRL client with the before/after-signing distinction, and PAdES/DSS-revision parsing. Teams that start here usually discover the gap after shipping.

Detail: JavaScript PDF signature libraries compared · VerifyKit vs pdf-lib

2. EU DSS

The European Commission's reference validator, and the most complete open-source answer that exists. Trust via EUTL, real revocation, full PAdES.

The constraint is the runtime: it is Java. If your stack is Node or a browser, DSS means running a JVM service and shipping documents to it — which changes your privacy story, your deployment story, and your latency story. For a Java backend it is an excellent choice and genuinely free.

3. Full document platforms — Apryse and Nutrient

Both verify signatures in the browser, and both do vastly more besides.

Both are strong products. Two things are worth knowing before you commit: verification is a licence component you buy in addition to the viewer, and each vendor's verification documentation covers less than its marketing does — so ask them directly about the rows above rather than assuming.

Detail: VerifyKit vs Apryse · VerifyKit vs Nutrient

4. VerifyKit

A Rust/WASM verification engine with a React and vanilla-JS viewer on top. It does not sign, edit, redact or OCR. What it does is answer all eight questions and hand you the evidence:

• Eight checks reported independently, each with its own status and detail string — integrityCheck, signatureCheck, certificateChainCheck, expiryCheck, timestampCheck, revocationCheck, algorithmCheck, ekuCheck.
• An attempted flag on each, separating "we never checked" from "we checked and the answer was inconclusive" — a configuration problem and a genuine unknown look identical otherwise.
• 134 embedded trust roots — 118 from the Adobe Approved Trust List plus the 16-certificate Indian CCA hierarchy — extensible in merge mode or replaceable entirely.
• The full certificate chain, 21 fields per certificate (subject, issuer, serial, validity, both fingerprints, key algorithm and size, key usage, EKU, key IDs, CRL distribution points, OCSP URLs, caIssuers URLs, policies) plus the raw DER, so any certificate or the whole chain exports as PEM, DER or .cer. The timestamping authority's own chain comes back the same way.
• PAdES B-B, B-T, B-LT and B-LTA, including the archival level that keeps a signature verifiable after both the signing certificate and its CA have expired.
• mdpPermission for DocMDP certification level, and isDeleted / deletedAtRevision for signatures removed in a later incremental update.
• The verdict drawn where Acrobat draws it. The green tick, red cross or yellow question mark renders inside the PDF canvas, on the signature field itself, in the widget's rectangle — not as an HTML badge floated over the page — and it shows the verdict that signature actually got, rather than the grey placeholder the signing tool left in the file. Verification runs on the original bytes and what reaches the renderer is display-only, so a download returns the untouched document; password-protected files are supported too. Over that canvas, every signature field — signed or unsigned — is an individually addressable interactive overlay with per-field detail behind it. Other AcroForm fields render read-only: this is a verification viewer, not a form filler.
• Parsing and cryptography run client-side — the PDF is never uploaded. Revocation is the exception by design: asking a CA whether a certificate is still valid is a network request. It is opt-in.
• The same engine runs headless in Node.js, so a browser check and a server check give identical verdicts.

It is licensed commercially, quoted per deployment. The demo is free to try on your own documents.

The honest matrix

"Not documented" means the vendor's own verification guide does not cover it. It is a question to ask them, not a proven absence.

When verification is not the whole job

Be honest about the requirement before comparing:

• You need to sign, edit, redact, OCR, or ship iOS and Android. Apryse or Nutrient. VerifyKit is read-only and does not try to compete here.
• Your backend is Java and documents can leave the browser. EU DSS, free and complete.
• You need integrity only, on a budget, and can accept no trust or revocation. The open-source JS route.
• The verdict is the product — a verification page, a compliance workflow, an audit trail, anywhere someone will ask "why did this fail" and expect an answer. That is the case VerifyKit is built for, and the eight checks, the certificate detail and B-LTA are why.
• Your documents are Indian. DigiLocker, Income Tax, MCA and GST PDFs are signed under the CCA hierarchy, which is not in the AATL. An AATL-only trust store reports every one of them as untrusted.

Try it on your own signed PDF in the live demo — the document is never uploaded. Then Core Concepts for the verification model, the Core API reference for the full result shape, and Revocation Checking. Licensing is by quote — get in touch.

References

• Apryse — Verify a PDF digital signature (WebViewer)
• Nutrient — Signature validation guide (Web)
• EU DSS — esig/dss on GitHub
• Adobe — Approved Trust List
• ETSI — EN 319 142-1, PAdES baseline profiles
• VerifyKit — Core API reference · Architecture · PAdES levels explained