P
PDFluentSDK
← EditorDownload
Guides

Migrate legacy PDFs and use WASM

This guide shows developers how to migrate from a legacy PDF stack and prepare PDF operations for WebAssembly.

On this page

Migrate from a legacy PDF stack

Many teams accumulate a mix of old tools: PDFBox for reading, iText for writing, custom scripts for forms, and shell wrappers around Ghostscript. Consolidate to one Rust crate.

  1. Audit your current PDF toolchain

    Before replacing anything, list every library and tool touching PDFs in your system. Common legacy stacks include PDFBox for reading, iText for writing, a separate form library, and Ghostscript invoked via Runtime.exec() or shell scripts. Each one has its own dependency, license, and failure mode.

  2. Replace reading and text extraction first

    Start with the lowest-risk part of the stack: reading documents and extracting text. This is typically handled by PDFBox or pdfminer and is safe to swap without changing any downstream logic. Verify output parity before moving to the next operation.

  3. Consolidate form filling and document writing

    Legacy stacks often use a different library for writing than for reading. Replace iText or pdftk form-filling with PDFluent's acroform API. Replace Ghostscript shell invocations with PDFluent's document manipulation methods. Each replacement removes a runtime dependency from your Docker image.

  • iText 5 is AGPL-licensed. If your team has been quietly ignoring this, migration to PDFluent resolves the license risk.
  • Shell wrappers around pdftk or Ghostscript are fragile — they depend on specific installed versions and break silently when the binary is missing. PDFluent eliminates all external process invocations.
  • If you are using PDFBox 2.x, note that PDFBox 3.0 changed several APIs. Rather than upgrading PDFBox, migrating to PDFluent at this point may be less work.
  • Migrate one operation type at a time and run both the old and new code in parallel on the same documents to verify output parity before decommissioning the old tool.

From server PDF to WASM

Move PDF operations from a server endpoint to a WebAssembly module running in the browser. PDFluent compiles to WASM. No server round-trips for basic PDF operations.

  1. Identify which PDF operations can move to the client

    Not every PDF operation belongs in the browser. Operations that work well in WASM: form filling, text extraction, annotation, metadata editing, and basic PDF creation. Operations that should stay server-side: high-security signing, server-only data injection, and compliance workflows requiring an audit trail.

  2. Build PDFluent as a WASM target

    PDFluent compiles to WebAssembly using wasm-pack. The output is a ~6 MB .wasm file (~2 MB Brotli-compressed over the wire) plus a JavaScript glue module. Add the wasm target to your Rust toolchain and run wasm-pack build to produce an npm-compatible package.

  3. Load the WASM module and replace the server calls

    Import the wasm-pack output as an ES module in your frontend code. Initialize the WASM binary once on page load, then call PDFluent operations directly in the browser. Replace fetch() calls to your server endpoint with direct WASM calls on the PDF ArrayBuffer.

  • The WASM binary is ~6 MB uncompressed (~2 MB over the wire with Brotli). Load it once and cache it with a Service Worker for offline support.
  • PDF signing with a server-held private key must stay server-side. WASM is appropriate for user-facing, non-sensitive operations.
  • WASM runs in a single thread by default in browsers. For large PDFs, consider Web Workers to avoid blocking the main thread.
  • If users upload PDFs to your server for processing, shifting to WASM also reduces GDPR surface area — the PDF bytes never leave the browser.