Why Client-Side PDF Verification Matters: A Privacy-First Approach

PDF documents often contain the most sensitive information in an organization — signed contracts, medical records, financial statements, legal filings, government IDs, and HR documents. When these files are uploaded to a server for signature verification, the document content is exposed to network transit, server-side storage, and potential third-party access.

VerifyKit takes a fundamentally different approach: all verification runs client-side in a WebAssembly sandbox. PDF bytes never leave the user's device.

The Problem with Server-Side Verification

Traditional PDF signature verification services work like this:

1. User uploads the PDF to a server
2. Server extracts and verifies signatures
3. Server returns results to the user
4. PDF may be stored, logged, or cached on the server

This creates several risks:

• Data in transit — Even with TLS, the PDF content crosses network boundaries
• Server-side storage — Many services retain uploaded documents for processing, caching, or analytics
• Third-party access — Cloud-hosted verification services may process documents in jurisdictions with different privacy laws
• Compliance burden — GDPR, HIPAA, SOC 2, and other regulations impose strict requirements on server-side document handling
• Supply chain risk — If the verification service is compromised, all uploaded documents are exposed

How Client-Side Verification Works

With VerifyKit, the verification pipeline runs entirely in the browser:

1. User loads a PDF — the bytes stay in browser memory
2. The Rust/WASM engine parses the PDF structure and extracts signatures
3. All cryptographic operations (hash computation, signature validation, certificate chain building) run inside the WASM sandbox
4. Results are returned to the JavaScript layer
5. PDF bytes are never transmitted to any server

import { createVerifier } from '@trexolab/verifykit-core'
 
// pdfBuffer stays in browser memory the entire time
const verifier = await createVerifier()
const result = await verifier.verify(pdfBuffer)
// No network requests for verification (except optional revocation checking)

WASM Sandbox Isolation

WebAssembly provides memory isolation by design:

• The WASM module operates in its own linear memory space
• It cannot access the JavaScript heap, DOM, or browser APIs directly
• All data passes through a narrow, well-defined interface
• The sandbox prevents buffer overflows from escaping into the host environment

This means even if there were a vulnerability in the PDF parsing code, it would be contained within the WASM sandbox.

Zero Telemetry

VerifyKit collects no telemetry, no analytics, and no usage data. There are no tracking pixels, no phone-home requests, and no external service dependencies for core verification.

The only network requests that can occur are:

1. AIA certificate chain resolution — Fetching missing intermediate certificates from CA-provided URLs (enabled by default, can be disabled)
2. Online revocation checking — CRL/OCSP requests when the revocation plugin is installed (opt-in)

Both of these fetch certificate infrastructure data, not document content. The PDF bytes themselves never leave the browser.

Compliance Benefits

When You Still Need Server-Side

Client-side verification is ideal for interactive user-facing workflows. But some scenarios require server-side processing:

• Automated batch processing — Processing thousands of PDFs without user interaction
• CI/CD pipelines — Validating signed documents as part of a build process
• API-driven workflows — External systems sending PDFs for verification

VerifyKit supports both: the same @trexolab/verifykit-core package runs in the browser and in Node.js 20+, Deno, and Bun. You can use client-side for interactive verification and server-side for automated workflows — same API, same verification results.

Performance

A common concern with client-side processing is performance. VerifyKit's Rust/WASM core delivers 3.7x faster verification than equivalent JavaScript implementations. The WASM binary is base64-embedded in the JavaScript bundle (no external files to host), and first-use initialization takes just 20-50ms.

For most signed PDFs, complete verification (all 8 checks across all signatures) completes in under 100ms on modern hardware.

The Architecture

User's Browser
├── JavaScript Layer (React / Vanilla)
│   ├── PDF.js (rendering)
│   └── VerifyKit JS (orchestration)
└── WASM Sandbox (isolated memory)
    ├── PDF parser
    ├── CMS/PKCS#7 processor
    ├── X.509 chain builder
    ├── RSA / ECDSA / Ed25519 verifier
    ├── SHA-256/384/512 hasher
    └── AATL trust store (119 roots)

All cryptographic operations happen inside the WASM sandbox. The JavaScript layer handles UI, file I/O, and result presentation — but never performs any cryptographic computation itself.

Next Steps

• Live Demo — Verify a signed PDF without uploading it anywhere
• Architecture — Technical deep dive into the WASM engine
• Security — Full security model documentation
• Contact Us — Questions about privacy compliance?