We got tired of PDF libraries that crashed on real-world documents, ignored XFA entirely, or shipped a large C++ build just to read a form field. Every library we evaluated either failed on slightly malformed files or dragged in a full PDFium build with its own set of C++ vulnerabilities.
So we started building a PDF parser in Rust, from scratch, for production. It worked. Then came the XFA engine. Then a renderer. Then a PDF/A converter. At some point it became a proper SDK, one we would trust in a production pipeline. In 2026 we published it, and the desktop editor has been generally available since 1.0.0 on 2026-09-18 [B45, 2026-09-18].
PDFluent is the result. The XFA engine is tested against an internal corpus of enterprise documents (government forms, banking forms and other complex interactive PDFs), with crash-safety and per-document timeout gates across the full corpus. Visual fidelity versus reference output is an active improvement area; we do not yet make a published fidelity claim. The PDF/A converter handles the full breadth of documents the industry actually produces.
The parser, XFA engine, and renderer are written in Rust, with no C++ library underneath and no C++ exceptions to catch.
Compile to WebAssembly and the same code runs in the browser without a server. Useful for client-side previews, offline processing, or reducing API round-trips.
XFA (XML Forms Architecture) is a long, complex spec that PDFBox, MuPDF and Nutrient do not implement. PDFluent parses, evaluates FormCalc scripts, and flattens XFA forms to standard PDF.
Not spec examples: enterprise XFA documents across the xfa-forms, xfa-golden, and xfa-extra subsets (US, Canada, IRS, GSA, VA government forms among them). Crash-safety and per-document timeout gates pass across the full corpus.
In safe Rust the ownership model rules out buffer overflows and use-after-free.
Rust, Python (PyO3), Node.js (napi-rs), Java (JNI), C (cdylib header), and WebAssembly. Same underlying engine everywhere.
We invest in engineering, not enterprise sales. No account executives, no lengthy procurement cycles — just a quality SDK you can evaluate, license, and integrate on your own timeline.
Licensing is online and instant. If you run into a payment issue or need to arrange things differently, email us and we'll work it out.
We keep headcount deliberately low and engineering standards deliberately high. A focused team produces more reliable software than a large one with competing priorities. We'd rather ship correct behaviour than ship fast.
We don't do sales calls. We do answer every technical question. Email [email protected] and you'll hear back from someone who wrote the code — not a support tier.
Founder, PDFluent
Questions about integration, licensing, or something PDFluent doesn't support yet? We respond to everything.