How browser-based PDF signature verification works, what formats VerifyKit supports, and how it compares to alternatives.
Yes. VerifyKit runs the entire signature verification pipeline — byte-range hashing, CMS/PKCS#7 parsing, certificate chain trust validation, revocation checking — inside the browser or Node.js process. The PDF never leaves the device. The cryptographic engine is compiled from Rust to WebAssembly, so the same code path runs on every platform.
Yes. The core SDK (@trexolab/verifykit-core, -react, -vanilla, -plugin-revocation) is free for both commercial and non-commercial use under the project license. There is no hosted service, no per-verification fee, and no API key to obtain.
The 8-point verification model mirrors Adobe Reader DC's default behavior. VerifyKit ships with the Adobe Approved Trust List (AATL) root store, detects PAdES B-B / B-T / B-LT / B-LTA, handles DocMDP certification signatures, and supports legacy adbe.pkcs7.sha1 signatures. Where Adobe treats SHA-1 signatures as valid, VerifyKit does too by default — this is configurable via `setAlgorithmPolicy`.
The compressed WASM payload is roughly 400 KB gzipped and is loaded on demand (not during initial page paint). Verification itself is CPU-bound for a few hundred milliseconds on a typical signed PDF. All crypto runs in the WASM sandbox, isolated from the host page's JavaScript heap.
adbe.pkcs7.detached, adbe.pkcs7.sha1 (legacy PDF 1.3), ETSI.CAdES.detached, and ETSI.RFC3161 document timestamps. Both Basic Signatures and PAdES Long-Term Validation (LTV) profiles are verified, including embedded certificate revocation data in the Document Security Store (DSS).
Yes. The @trexolab/verifykit-core package is a headless API with zero DOM dependencies and runs on Node.js 20+, Deno, and Bun. Use it for batch processing, CI/CD pipelines, automated compliance checks, or API-driven validation workflows.
Revocation data embedded inside the PDF (DSS / VRI blocks) is consulted first — this is how PAdES B-LT / B-LTA signatures stay verifiable offline. For online CRL and OCSP fetching, install @trexolab/verifykit-plugin-revocation; browsers proxy the requests through an endpoint you control to avoid CORS issues.
Yes. Pass a `trustStore` config to `createVerifier` with either `mode: 'merge'` (additive, the default AATL list stays) or `mode: 'replace'` (only your PEM list is trusted). Useful for enterprise CAs, national eID roots, and restricted-trust deployments.
Yes, from v0.5.3. Every CertificateInfo includes a `rawDer` Uint8Array. The React viewer's Signature Properties dialog has built-in export (PEM, DER, PKCS#7 bundle, and a ZIP of every certificate in the chain). For custom UIs, call `buildCertChainPkcs7(certs)` to produce a .p7b blob.
PDF.js renders signed PDFs but does not cryptographically verify the signatures — the green check you see in Adobe Reader is not something PDF.js emits on its own. VerifyKit adds the missing verification layer on top, exposing an Adobe-style verdict, a full 8-point check breakdown, and a ready-made React viewer that composes with or replaces PDF.js rendering.
The technical checks (byte-range integrity, CMS crypto, chain trust, PAdES conformance, timestamp validation, LTV revocation) align with the eIDAS regulation's requirements for qualified electronic signatures. Legal enforceability depends on factors beyond the SDK — trusted list provisioning, timestamp authority certification, and jurisdiction-specific policy.
Open the live demo at https://verifykit.trexolab.com/demo and drop any signed PDF on the page. All processing happens in your browser — the file is never uploaded.