PDFluent is a pure-Rust PDF SDK engineered in the Netherlands. No C++ at the core, no PDFium under the hood, no memory corruption bugs. It runs natively and in the browser — same code, same behaviour.
We got tired of PDF libraries that crashed on real-world documents, quietly ignored XFA entirely, or shipped 80 MB of C++ 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 in 2024 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'd actually trust in a production pipeline.
PDFluent is the result. The XFA engine has been validated against an internal corpus of 1,150 enterprise documents — government forms, banking forms, and other complex interactive PDFs — passing crash-safety and 30-second-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 safe Rust. No FFI boundary to cross, no C++ exceptions to catch, no need to ship a platform binary for every OS.
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 1,000-page spec that almost every modern PDF library ignores. PDFluent parses, evaluates FormCalc scripts, and flattens XFA forms to standard PDF.
Not spec examples — 1,150 enterprise XFA documents across xfa-forms, xfa-golden, and xfa-extra subsets (US, Canada, IRS, GSA, VA government forms among them). Crash-safety and 30-second-per-document timeout gates pass across the full corpus.
Rust's ownership model catches entire classes of bugs at compile time. No buffer overflows, no use-after-free, no null pointer dereferences. The kind of bugs that fill PDF-library CVE lists.
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. We support payment methods across 100+ countries. If you run into a payment issue or need to arrange things differently, email us — 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 hello@pdfluent.com and you'll hear back from someone who wrote the code — not a support tier.
PDFluent is built by a small, focused team of engineers based in the Netherlands. We believe the best software infrastructure comes from people who use what they build — and who care more about correctness than roadmap theatre.
Questions about integration, licensing, or something PDFluent doesn't support yet? We respond to everything.