Does PDF.js Verify PDF Signatures? VerifyKit vs PDF.js

If you have ever opened a signed PDF in Adobe Reader and seen the green "Signed and all signatures are valid" banner, you might expect a web-based PDF library to show the same thing. It is one of the most common misconceptions in web PDF work: PDF.js renders signed PDFs, but it does not cryptographically verify their signatures. This post explains the difference and where VerifyKit fits.

What PDF.js actually does

PDF.js is Mozilla's PDF rendering engine — the same one built into Firefox. It parses the PDF file format and paints pages to a canvas. It is excellent at what it does: text, vector graphics, images, form fields, and annotations.

What it does not do is evaluate the cryptography behind a digital signature. PDF.js can see that a signature field exists and render its visible appearance (the little signature stamp), but it does not:

• hash the signed byte range and compare it against the signature,
• parse the CMS / PKCS#7 signature container,
• build and validate the signer's X.509 certificate chain,
• check certificate revocation (CRL / OCSP),
• or determine PAdES conformance.

So the green checkmark you see in Adobe is a verdict PDF.js never computes. Rendering the appearance of a signature is not the same as verifying it — a tampered document can still display a signature stamp.

What signature verification actually requires

Cryptographic verification of a signed PDF is a pipeline, not a single check. A faithful verifier has to:

1. Integrity — recompute the hash over the signed ByteRange and confirm the document has not been altered after signing.
2. Signature — verify the CMS/PKCS#7 SignedData (RSA, ECDSA, or Ed25519) against the signer's public key.
3. Certificate chain — build a path from the signer certificate up to a trusted root.
4. Trust — decide whether that root is trusted (e.g. via the Adobe Approved Trust List, or your own CA set).
5. Expiry — confirm the certificate was valid at signing time.
6. Timestamp — validate any RFC 3161 timestamp token.
7. Revocation — consult CRL / OCSP data (embedded for LTV, or fetched online).
8. Algorithm & key usage — enforce a policy on weak algorithms and check Extended Key Usage.

This is exactly the 8-point model VerifyKit implements. None of it is part of PDF.js.

VerifyKit vs PDF.js at a glance

They are not competitors — they compose

The important point: you do not replace PDF.js with VerifyKit. VerifyKit uses PDF.js for rendering and adds the verification layer on top. In a React app you get a viewer that renders pages and surfaces a real Adobe-style verdict with a full breakdown of the eight checks. If you already render PDFs with PDF.js, VerifyKit slots in beside it rather than ripping it out.

For a deeper look at the model, see Core Concepts and the Quick Start. If you need this outside the browser, VerifyKit also runs headless in Node.js.

When you need VerifyKit

Reach for verification (not just rendering) when the validity of the signature matters to your users or your compliance posture:

• contract and e-signature platforms that must prove a document is untampered,
• government / eID workflows aligned with eIDAS and PAdES,
• document management systems that display a trustworthy "verified" badge,
• back-office pipelines that batch-check signed PDFs server-side.

If all you need is to display a PDF, PDF.js alone is fine. The moment you need to answer "is this signature actually valid, and do we trust the signer?", that is a cryptographic verification problem — and that is what VerifyKit is built for.

Try it on your own signed PDF in the live demo — everything runs in your browser, and the file is never uploaded.