Both are actually already supported! We have pdf_decrypt (which unlocks password-protected PDFs given the password) and pdf_sign for applying cryptographic signatures, as well as pdf_validate_signatures for verifying certificates.

Yes! We have an official desktop GUI for macOS, Windows, and Linux built with Tauri 2 and Svelte 5 (with native dark mode, visual diff, and a visual pipeline builder). We also have the full browser-based GUI running client-side via WASM at https://usepaperpilot.com/

FYI the box with the tool you've selected (where you upload and set parameters) is way too small on mobile. By scrolling you can use it, but you can only see a tiny bit of the interface at a time. Firefox on Android.

Huge respect for your work on printpdf, and thank you for chiming in!

When we evaluated the Rust PDF landscape, printpdf was actually one of the first crates we looked at for PDF generation. The reason we opted for a stack centered around lopdf and pdf-writer was architectural: PaperPilot's primary focus is heavy manipulation and non-destructive AST transformation of existing, arbitrary, often malformed real-world PDFs (re-ordering cross-reference tables, granular /P permission bitmask hashing, raw object streams, page imposition, booklet folding, and outline splitting).

For document synthesis (HTML/Markdown to PDF), typography and edge-cases (like the RTL/footnote issues you mentioned) are notoriously hard, and we'd love to learn from or collaborate with printpdf's battle-tested approaches there. Thank you for the feedback and all your contributions to Rust's PDF ecosystem!

Definitely not! There is zero MuPDF code, FFI, or transpilation in PaperPilot.

The core PDF parsing and AST manipulation is built on pure Rust libraries: lopdf (0.45), pdf-writer, hayro, and image. All of these are Apache 2.0 or MIT licensed.

Any mention of MuPDF in the documentation/planning notes was strictly part of an architectural trade-off analysis (evaluating existing Python/C extraction pipelines like PyMuPDF vs. pure Rust). The entire crate stack in paperpilot-pdf is 100% Apache 2.0 / MIT clean.

Hi HN,

I built PaperPilot because I was frustrated by the privacy trade-offs of modern PDF utilities.

Whenever you need to split, merge, compress, or sign a confidential document (tax forms, legal contracts, medical paperwork) using online tools, your files are transmitted to a third-party server. Most "free" tools retain copies or run in closed-source cloud environments.

PaperPilot is a 100% zero-cloud, local-first engine written in pure Rust (built on top of lopdf, pdf-writer, and image). 0 bytes are ever sent to an external server.

Key aspects of the project:

1. Penta-Interface Architecture: Instead of building just another web app or CLI, the same core Rust operations run across 5 surfaces: - Terminal CLI: High-throughput local processing and bash scripting. - Local Desktop App: Native cross-platform GUI built with Tauri 2 and Svelte 5. - Client-Side Web: Runs 100% inside your browser via WebAssembly (https://usepaperpilot.com/). - REST / Gateway API: Standalone local daemon (localhost:7823) for local microservices. - Model Context Protocol (MCP): Connects local AI agents (Claude Desktop, Cursor, OpenCode) directly to local PDF tools so LLMs can inspect, redact, and sign PDFs on disk without cloud upload.

2. Capabilities (75+ Tools): - Standard operations: Merge, split, rotate, reorder, burst, booklet imposition, and N-up grid. - Privacy & Compliance: Local PII regex redaction (SSNs, cards, emails), metadata striping, and digital signature verification. - Document Extraction: PDF to structured Markdown tables (no coordinate loss), PDF to JSON, and pure-Rust layout analysis. - Offline RAG: Embedded vector store (libsql_vector) with an actionable visual citation canvas.

3. Performance & License: - Average operation latency is ~20ms to 130ms. - 100% Free and Open Source under the Apache 2.0 license.

The GitHub repository is at https://github.com/KrushnaVardhanReddy/PaperPilot and the browser-based WASM sandbox is live at https://usepaperpilot.com/.

I’d love to hear your feedback on the architecture, performance benchmarks, and any edge-case PDF formats we should test against!

Is there anything in this project that was not already easily available with command line tools?

Yes, it's wasm. So you can run it in any browser. Super useful when no cli. Example on friend phone

I really like the approach with WASM and the browser sandbox. That alone makes this very usable. iam also working on an agent harnes in the browser sandbox called "hermit" using a local inference endpoint. It runs Python in WASM with a virtual file system.

https://moooff.github.io/HermitUI/hermit-agent/

So this Tool comes in very handy and will try to integrate it.

who doesn't need to merge and compress bunch of pdfs on a friend phone on a saturday morning

Yeah, it has to be a friend phone as mine has command line via ssh (and tailscale).

Congrats with your product, hope it works out well. Nice competitor analysis & (future) features list at https://github.com/KrushnaVardhanReddy/PaperPilot/blob/main/..., IMHO easier to read than your above list.

Question: seemingly you’re using Antigravity, an harness not many use. Please tell use about the choice of LLM and your experience with it.

Thanks for checking out the docs! We used a hybrid workflow: Antigravity IDE paired with Jules for asynchronous sub-tasks (like spinning up isolated unit tests and docs in parallel containers).

Having a strict test-first harness where every PR has to run against real PDF byte fixtures (zero mocks) and compile across CLI, WASM, and MCP kept the codebase consistent even when moving fast.

Thanks for your reply. Will look into Jules [0] [1].

Are you using Antigravity IDE v2.5.5 that hasn't been updated since 2026-08-13 and that supports 3 legacy models + Gemini Flash 3.8? I assume you're using Gemini Flash 3.8?

[0] https://news.ycombinator.com/item?id=44034918 [1] https://news.ycombinator.com/item?id=44813854

Is this a port of MuPDF?