VerifyKit vs pdf-lib: Creating PDFs vs Verifying Signatures

pdf-lib is one of the most popular PDF libraries in the JavaScript ecosystem, so it is natural to reach for it for anything PDF-related — including "can it check whether this signed document is valid?" The short answer is no, and that is not a criticism. pdf-lib and VerifyKit solve two different problems: pdf-lib creates and edits PDFs; VerifyKit verifies digital signatures. This page explains the difference and when you would use each — or both together.

What pdf-lib is built for

pdf-lib's own description is precise: "Create and modify PDF documents in any JavaScript environment." That is exactly what it is excellent at:

create documents from scratch, and — unusually — modify existing ones;
draw text, vector graphics, and images; embed fonts;
fill and flatten AcroForm fields;
set metadata, attachments, and viewer preferences;
run everywhere — Node, browser, Deno, React Native — with no native dependencies.

If your job is to assemble, fill, or edit PDFs, pdf-lib is a great choice.

What pdf-lib does not do

pdf-lib has no signature functionality of any kind — it neither applies digital signatures nor verifies them. The terms PKCS#7, CMS, X.509, certificate, PAdES, OCSP, and CRL do not appear in its documentation at all. (It also does not support encrypted documents.) There is no verify() in pdf-lib, and loading a PDF to inspect its structure is not the same as validating a signature over it.

That matters because signature verification is a cryptographic pipeline, none of which pdf-lib performs:

Integrity — hash the signed ByteRange and confirm nothing changed after signing.
Signature — validate the CMS/PKCS#7 SignedData against the signer's public key.
Certificate chain — build a path from the signer certificate to a root.
Trust — decide whether that root is trusted for document signing (AATL / EUTL / your own CA set).
Expiry — confirm the certificate was valid at signing time.
Timestamp — validate any RFC 3161 timestamp.
Revocation — consult CRL / OCSP data.
Algorithm & key usage — enforce a policy on weak algorithms and check Extended Key Usage.

pdf-lib can open the file and read its objects, but it never computes any of this. Parsing a PDF's structure is not verifying the signature inside it.

They are complementary, not competitors

Because the two libraries do different jobs, the common real-world setup uses both:

pdf-lib to generate, fill, or edit documents on the way out.
VerifyKit to verify signed documents on the way in — proving a received contract is untampered and identifying who signed it.

You do not choose pdf-lib instead of VerifyKit any more than you would choose a word processor instead of a signature validator. If you are already using pdf-lib and now need to answer "is this signature valid, and do we trust the signer?", that is the gap VerifyKit fills.

Where VerifyKit fits

VerifyKit is a commercial, licensed SDK built specifically for verification. Its Rust/WASM engine runs the full 8-point pipeline above — including a built-in AATL trust store, CRL/OCSP revocation, and PAdES B-B / B-T / B-LT / B-LTA detection — entirely client-side (the PDF is never uploaded), and the same engine runs headless in Node.js. It mirrors Adobe Reader's valid / unknown / invalid verdict, so an intact document from an untrusted signer reads as "unknown," not "invalid."

At a glance

Capability	pdf-lib	VerifyKit
Create / modify PDFs	Yes	No (not its job)
Fill / flatten form fields	Yes	No
Apply a digital signature	No	No (verification-focused)
Verify a signature (integrity)	No	Yes
CMS / PKCS#7 validation	No	Yes
Certificate chain + AATL trust	No	Yes
CRL / OCSP revocation	No	Yes
PAdES B-B / B-T / B-LT / B-LTA	No	Yes
Runs in browser + Node	Yes	Yes (Rust/WASM)
License	Open source (MIT)	Commercial SDK

How to choose

Building, filling, or editing PDFs? pdf-lib.
Verifying signed PDFs — trust, revocation, PAdES levels? VerifyKit.
Doing both (assemble documents and verify incoming signed ones)? Use them side by side — pdf-lib for authoring, VerifyKit for verification.

For a wider view of the ecosystem — @signpdf, PDF.js, the verify-pdf family, PKI.js, EU DSS — see Verifying PDF Signatures in JavaScript: A Library Comparison. For the verification model itself, see Core Concepts. Or try it on your own signed PDF in the live demo — everything runs in your browser.

References

pdf-lib — documentation · README · npm (create/modify feature set; no signature APIs)