PDFluent
For developers Download
Complete Feature Set

Everything your
PDF pipeline needs.

From parsing and rendering to XFA forms, compliance, OCR, and digital signatures, in one SDK with bindings for Rust, Python, Node.js, .NET, Java and WebAssembly.

XFA Forms Support

XFA 3.3 engine written in Rust. Flatten dynamic forms, extract data, execute FormCalc expressions.

  • Parse and render XFA templates
  • Execute FormCalc calculations
  • Extract structured data
  • Flatten to static PDF

Written in Rust

The engine is written in Rust.

  • No garbage-collected runtime
  • No JVM to install
  • Measured figures on /benchmarks/

WebAssembly Ready

Compile to a WASM bundle that runs PDF processing entirely in the browser. The published @pdfluent/sdk-wasm@1.0.0 .wasm is 15.3 MB unpacked, 3.8 MB Brotli, 5.5 MB gzip [B07, 2026-09-16]. No server uploads: files stay on the user's device.

  • Browser-native execution
  • No server dependencies
  • Offline capable
  • Cross-platform compatibility

EU Compliance Built-in

PDF/A archiving, PDF/UA accessibility, and XRechnung/ZUGFeRD e-invoicing support out of the box.

  • PDF/A-1, 2, 3 validation
  • PDF/UA accessibility
  • ZUGFeRD e-invoicing
  • Long-term archiving

Digital Signatures

Create and verify PAdES signatures with LTV support, timestamping, and full certificate chain validation.

  • PAdES-B, T, LT
  • RFC 3161 timestamping
  • Certificate validation
  • Multiple signatures

Opt-in OCR

In pdfluent 1.1.0, OCR is reachable from Python only. It is off by default; turn it on to run through a system tesseract binary on PATH (or PDFLUENT_TESSERACT), or pass your own function with ocr_function=. From plain Rust, the pdfluent 1.1.0 crate does not reach tesseract.

  • Off by default
  • System tesseract binary (Python only)

No JVM or C++ runtime in the core

The core is Rust: no JVM, no C++ runtime, no system libraries. Native dependencies are opt-in: ONNX Runtime for the balanced extraction tier, a system tesseract binary for OCR. Deploy to containers, serverless functions, or air-gapped servers.

  • No Java runtime required
  • No C/C++ system libraries in the core
  • Single portable binary
  • WASM-compilable (no native deps)
Security

Built safe by default.

The SDK runs in production on untrusted, arbitrary PDFs from end users. That's a large attack surface.

Memory safety in safe Rust

In safe Rust the ownership model rules out buffer overflows and use-after-free. The checks run at compile time, not through a garbage collector.

What is native

The parser, interpreter and heavy decoders are Rust. Optional parts are native: the balanced extraction tier loads ONNX Runtime at run time, and OCR calls a system tesseract binary.

Sandboxable

The core is Rust, with no JNI and no dynamic linking to system libraries. The optional native parts, ONNX Runtime and tesseract, load only when you turn them on. The WASM build runs inside the browser sandbox.

A Rust core

Safe Rust rules out buffer overflows and use-after-free. The Chromium project reports around 70% of its serious security bugs are memory-safety problems [C21, 2026-10-15].

Statically-linked binary

Dynamically-linked native PDF libraries load shared objects (.so/.dll) into the host process; a vulnerability in the library compromises the process. PDFluent's Rust core links statically. Native dependencies are opt-in: the balanced extraction tier loads ONNX Runtime, and OCR calls a system tesseract binary.

Auditable single language

The engine is Rust, with no minified JS. Auditors can read the source of the core; the optional native parts, ONNX Runtime and tesseract, are open-source projects with their own source.

Relevant if you process PDFs from e-mail, web uploads, or external APIs — environments where files may be deliberately malformed or weaponised. Why memory safety matters

Ready to get started?

Free and complete under the AGPL. No watermark, no key, no credit card.

Download →View Pricing