VerifyKit vs Apryse WebViewer for PDF Signature Verification

Apryse (formerly PDFTron) is one of the two commercial SDKs that genuinely validate PDF signatures in the browser. If you are choosing between it and VerifyKit, the honest framing is that they are not the same kind of product: Apryse is a full PDF platform that also verifies signatures; VerifyKit is a verification engine that also renders PDFs.

This page compares them on what each one's own documentation and source say — with the API names quoted, so you can check every row.

The size difference, stated first

Apryse does a great deal that VerifyKit does not do at all:

• Editing, redaction, annotation, forms, conversion, OCR, page manipulation.
• Signing. Apryse applies signatures. VerifyKit does not sign anything — it is read-only by design.
• Platform reach. Apryse ships SDKs for iOS, Android, .NET, Java, C++, Python and server-side deployments. VerifyKit is JavaScript/TypeScript: browser and Node.js.

If any of those are on your list, the comparison ends here and Apryse is your answer. What follows is only about the verification verdict itself.

What Apryse's verification returns

Apryse documents two tiers. The higher-level one returns a document-wide enum, PDFDoc.SignaturesVerificationStatus, with five values:

Two details in that list are worth pausing on, because they are design decisions rather than accidents.

e_untrusted is deliberately kept out of e_failure. Apryse's own explanation is that trust issues are "flaky due to being network/config-related" — so an intact document from a signer you have not configured trust for is reported separately from a document that failed cryptographically. VerifyKit reaches the same conclusion by a different route: it mirrors Adobe's semantics, where that case reads unknown rather than invalid (see Why Adobe Says "Signature Validity Is Unknown"). Both are right; neither collapses trust into failure.

e_unsupported has no VerifyKit equivalent, and that is a point for Apryse's honesty — it tells you when it met a construct it could not handle, and the detailed API's GetUnsupportedFeatures enumerates which. Apryse's guidance when you hit it is to contact them.

The lower-level API returns a VerificationResult per signature, from which you can reach a DigitalSignatureField and call GetByteRanges to confirm coverage or inspect a prior revision.

What VerifyKit's verification returns

VerifyKit has no document-level summary enum as its primary output. Every signature carries eight independently-reported checks, each with its own status, a human-readable detail string, and — for revocation — an attempted flag that separates "not checked" from "checked, and the answer was inconclusive":

integrityCheck          signatureCheck        certificateChainCheck   expiryCheck
timestampCheck          revocationCheck       algorithmCheck          ekuCheck

Each is a SignatureCheckResult with status (valid / invalid / warning / unknown / pending), detail, and optionally algorithmName so a UI can display "signed with SHA-1" regardless of whether that check passed.

Alongside them, per signature: padesLevel, mdpPermission (the DocMDP certification level), subFilter, byteRangeCoverage and byteRangeCoversWholeFile as separate booleans, isVisible, signingTime, reason, location, contactInfo, and — for documents where a signature was removed in a later revision — isDeleted with deletedAtRevision.

The difference is not "more data for its own sake." It is the difference between telling a user "this document failed" and telling them "the bytes are intact and the signature is cryptographically sound, but the signing certificate expired in 2024 and there was no timestamp to prove it was valid when signed." The second sentence is only constructible if the eight checks are reported separately.

Where the verdict is drawn

Most web PDF viewers report a signature by floating a badge over the page in HTML. VerifyKit does that too — but it also does what Acrobat does, which is put the verdict inside the PDF canvas, on the signature field itself, in the widget's own rectangle at the right scale and rotation. A signed document opened in VerifyKit and the same document opened in Acrobat show the green tick, red cross or yellow question mark in the same place, on the same field.

The important part is that the icon reflects the verdict that signature actually got from the eight checks, not the placeholder the signing tool baked in. An unvalidated signed PDF normally carries a grey question mark; most web viewers render exactly that, forever, because they draw what is in the file. VerifyKit draws the computed result.

Three properties are worth stating, because they are what makes this safe to switch on:

• Verification runs on the original, unmodified bytes. What is handed to the renderer is display-only, and a download gives you back the untouched file, byte for byte.
• Password-protected documents are supported too, not skipped and not corrupted — the common failure mode for anything that rewrites a signed, encrypted PDF.
• The signer's own appearance is never invented. Where a document's signature field cannot carry a status icon, VerifyKit leaves it alone rather than drawing something misleading over it.

On top of that canvas, every signature field — signed and unsigned alike — is an individually addressable interactive overlay, positioned on the widget's rectangle, tinted by that signature's status, with hover and highlight states and a click-through to the full per-field detail: the eight checks, the certificate chain, the timestamp and the PAdES level.

One honest limit: VerifyKit renders other AcroForm fields read-only. It is a verification viewer, not a form filler — if you need fillable forms, that is Apryse's job, not this one.

Apryse's verification guide documents the result object rather than the rendering, so there is nothing to compare it against here; WebViewer certainly renders signature appearances, and whether it updates them to match a computed verdict is a question for them.

Certificate detail

Apryse's verification guide does not document reading certificate fields — subject, issuer, serial, validity, fingerprint or chain contents do not appear on it. That does not mean the SDK cannot; it means it is not part of what the verification page promises, and you would be looking elsewhere in a large API surface.

VerifyKit returns the full parsed chain, and every certificate in it carries:

subject · issuer · serial number · notBefore / notAfter · isExpired · isCA · subjectAltNames · SHA-256 fingerprint · SHA-1 fingerprint · key algorithm · key size · signature algorithm · key usage · extended key usage · subject key ID · authority key ID · CRL distribution points · OCSP URLs · caIssuers URLs · certificate policies · and the raw DER bytes.

The raw DER is there for one reason: so a UI can offer per-certificate and whole-chain export as PEM, DER or .cer without a second parse. Timestamp tokens get the same treatment — timestamp.tsaCertificates is a full CertificateInfo[] for the timestamping authority's own chain, not just a name string.

Trust

Both let you supply your own roots. Apryse's is VerificationOptions.addTrustedCertificateFromURL(...), which adds a root to the store held on the options object.

VerifyKit ships a trust store rather than starting empty: 134 embedded root certificates — 118 from the Adobe Approved Trust List, plus the 16-certificate Indian CCA hierarchy (the CCA 2014/2015/2022 roots and the licensed CAs beneath them: eMudhra, Capricorn, Protean, SafeScrypt, IDRBT, XtraTrust, PantaSign, NCode, IDSign, Verasys, C-DAC, CSC). Your own certificates go in through a trustStore config with a merge or replace mode, so you can extend the built-in set or substitute your own entirely.

That Indian CCA set is worth calling out because it is not in the AATL. A DigiLocker document, an Income Tax acknowledgement, an MCA filing or a GST return is signed under the CCA hierarchy, and against an AATL-only trust store all of them come back as untrusted despite being perfectly valid. If your documents are Indian, this is the row that decides it.

PAdES

Apryse's verification guide does not use the term PAdES; LTV and timestamping appear as sidebar links rather than in the verification text. Again — not a claim that the SDK lacks it, a statement about what that page commits to.

VerifyKit classifies every signature as B-B, B-T, B-LT or B-LTA and exposes it as padesLevel, with a dedicated UI tab that shows which level a signature reached and what it would need for the next one.

Setup cost

Two practical differences that only show up after you have chosen:

• Apryse's verification requires WebViewer({ fullAPI: true }). The full API is a substantially larger payload than the default viewer build, and it is a prerequisite, not an optimisation.
• Apryse lists a Digital Signature package as a separate production licence component; trial keys have everything unlocked, which means the constraint appears at the point you go live rather than while you are evaluating.

VerifyKit's engine is one WASM module with verification built in — there is no separate verification package to license, and no viewer-mode flag that turns cryptography on. pdf.js is bundled and loaded lazily, so the rendering weight arrives only when a document does.

At a glance

Rows marked "not documented there" mean exactly that — Apryse's verification guide does not cover them. Treat them as questions to ask Apryse, not as established absences.

How to choose

• You need one SDK for editing, forms, signing and mobile. Apryse. VerifyKit does not compete for that job and does not try to.
• You need to sign PDFs. Apryse. VerifyKit is read-only.
• You need the verdict itself to be detailed — which of the eight checks failed, what the certificate chain contains, which PAdES level was reached, whether the certificate is CCA- or AATL-rooted. That is what VerifyKit is built for.
• Your documents are Indian government or enterprise PDFs. The embedded CCA hierarchy is the practical difference.

Try VerifyKit on your own signed PDF in the live demo — the document is never uploaded — then see Core Concepts for the verification model and the Core API reference for the full result shape. Licensing is by quote: get in touch.

References

• Apryse — Verify a PDF digital signature (WebViewer) · WebViewer product page
• VerifyKit — Core API reference · Architecture · Revocation checking
• Related: VerifyKit vs Nutrient · JavaScript PDF signature libraries compared