PDFluent SDK's answer

This fits developers who need to process real-world PDFs that include XFA forms - often from government or banking sources - and want a single SDK that works consistently across Python, Node.js, Java, C, Rust, and WebAssembly without managing native binaries for each platform.

KeptPDF's answer:

Anyone who has to hand a document to someone else and needs the sensitive parts gone first.

In practice that is solo attorneys and small law firms, accountants and tax preparers, healthcare and records staff handling requests, HR teams, and individuals dealing with their own medical, legal, or financial paperwork.

The common thread is not an industry. It is a person who cannot upload a confidential file to a random website, and who does not have an enterprise IT budget to solve it.

PDFluent SDK's answer

PDFluent SDK parses XFA, a 1,000-page specification that almost every modern PDF library ignores. It evaluates FormCalc scripts and flattens XFA forms to standard PDF, validated against an internal corpus of 1,150 enterprise documents including US, Canadian, IRS, GSA, and VA government forms plus banking documents. XFA support is experimental and has no published fidelity claim.

KeptPDF's answer:

KeptPDF runs entirely in your browser. Your file, and the text inside it, never leaves your device. Not to an AI, not even to us. You can open your browser's network tab and watch: the document bytes never go out.

Most online PDF tools upload your file to a server first, and some "AI redaction" services quietly send your document text to a third-party model. That is the exact risk people are trying to avoid when they redact something.

KeptPDF also does true redaction. The text is removed from the file, not covered with a black box you can copy out later. Every redaction produces a verification certificate you can share with the file.

PDFluent SDK's answer

Because the SDK is pure Rust with no C or C++ dependencies, there is no FFI boundary inside the engine, no C++ exceptions to catch, and no platform binary to ship per OS. This eliminates the deployment complexity of dragging in a full PDFium build.

KeptPDF's answer:

Three reasons.

Privacy you can verify, not just a promise. Processing happens locally in the browser, so there is no upload step to trust. We do send anonymous usage counts for quota, and we say so plainly, but never your document.

Real redaction with proof. Removed text is permanently gone, and you get a certificate showing the file was checked for leftover extractable text. Automated detection cannot catch everything, so a final human review is still your job, and the tool says that too.

It works on a phone. Most PDF suites assume a desktop. KeptPDF was built and used on a phone first, so redacting a document while you are standing in a hallway actually works.

PDFluent SDK's answer

The team got tired of PDF libraries that crashed on real-world documents, ignored XFA entirely, or shipped 80 MB of C++ just to read a form field. They started building a parser in Rust from scratch, then added an XFA engine, a renderer, and a PDF/A converter. The company is Innovation Trigger B.V., based in the Netherlands.

KeptPDF's answer:

A family member got seriously ill. We spent most days at the hospital, and straight answers were hard to come by, so we leaned on AI tools to make sense of the records, notes, and lab results.

But you cannot paste a medical record into an AI chat. You have to strip the names, the ID numbers, the diagnoses first. And almost every tool we found either wanted to upload the whole file to a server, or "auto-redacted" by sending the document text to an online AI. That was the exact thing we were trying to avoid.

Most of this was happening on a phone, at a bedside. So I built the tool I needed: redaction that runs on the device, works on mobile, and never sends the file anywhere. That turned into KeptPDF, which is now a full PDF suite with over 20 tools, all local-first.

PDFluent SDK's answer

PDFluent is built in pure Rust with no C or C++ dependencies. It provides bindings via PyO3 for Python, napi-rs for Node.js, JNI for Java, a cdylib header for C, native Rust, and WebAssembly (2.5 MB brotli-compressed). The same engine runs across all surfaces.

KeptPDF's answer:

The app is plain JavaScript with no front-end framework, which keeps it fast and keeps the code auditable.

PDF work happens in the browser using pdf.js for rendering and pdf-lib for writing. Text recognition uses Tesseract running as WebAssembly. Password and encryption handling uses a WebAssembly build of qpdf. It is a Progressive Web App, so it installs and works offline.

The thin server side is Node on Vercel, with Postgres for accounts, Stripe for billing, and Resend for email. None of those ever see a document.

KeptPDF's answer:

KeptPDF is early and independent, and we do not publish customer names. The product is privacy-first by design: we never see your documents, and we do not track who our users are or what they work on. Publishing a client list would sit badly next to that.

The user base today is mostly solo attorneys, small firms, accountants, and individuals handling their own records.