The core and CLI are shining, but the GUI might as well be a basic viewer. I have split it off into its own project with a proper plan. If you need a fast RUST native pdf GUI editor and are planning it as an LLM project the core from this should save you weeks of time. If you need a CLI tool to use with your LLM to interact with pdf documents, this might be your tool of choice to do that too.
An open-source, non-monetized PDF editor for Windows, written in Rust. The long-term goal is feature parity with Adobe Acrobat Pro; it is not there yet, and the sections below say plainly what does and does not work today.
It is a native desktop application — no web server, no browser runtime,
no local network listener. It runs from a single folder, dependencies
included, no installer. Alongside the GUI it ships pdfce-cli, a
first-class scriptable command line with 108 subcommands, which is
deliberately not a debug tool: Acrobat Pro has no real equivalent.
Working today, among other things: opening and rendering PDFs; page operations (merge, split, extract, insert, delete, reorder, rotate); text extraction and text editing with reflow; AcroForm field creation, editing, filling, flattening and FDF/XFDF import/export; markup annotations; redaction (mark, review and apply); Bates numbering; PDF/A validation and conversion; digital-signature inspection; vector object and node editing; measurement and dimension authoring; image placement from PNG, JPEG, BMP and TIFF; printing, with page placement, orientation, duplex, copies and n-up/booklet/poster imposition; and opening password-protected documents — RC4 40–128 bit and AES-128, including the empty-user-password case that opens with no prompt at all.
Not built yet, among other things: OCR, JavaScript, XFA, writing
an encrypted document (pdfce decrypts to read and edit, but cannot yet
write one back out), AES-256 and /R 6 decryption, and a long tail of
Acrobat Pro's surface. Some capabilities exist in pdfce-core and
pdfce-cli but have no GUI yet.
docs/FEATURES.md is the honest, current answer — a capability
list with per-surface (core / CLI / GUI) checkboxes, updated whenever a
feature lands rather than at release time. Read that before assuming
anything here is complete.
The latest release
is a single-folder portable build for Windows x64. No installer, no
registry writes: unzip it and run pdfce-gui.exe, or pdfce-cli.exe for
the scriptable side.
pdfce does not use the network. It contains no HTTP client and no TLS stack — you can confirm this yourself in
THIRD_PARTY_LICENSES.md, which lists every library linked into the binary. There is no telemetry, no analytics, no crash reporting, no licence check, and no update check. Every document you open is processed entirely on your machine.If you click a link inside pdfce, pdfce hands the address to your operating system's default browser. The request is made by your browser, not by pdfce.
Updates are manual: download the new zip and replace the program files (keep your
userdatafolder). pdfce will never update itself.Supported platform: Windows 10/11, 64-bit. pdfce's code is kept portable and is compiled for Linux, macOS, and WebAssembly on every change, but those builds are not tested or supported, and no artifact is published for them.
The download is not code-signed. Windows will show a SmartScreen warning ("Windows protected your PC") the first time you run it; choose More info → Run anyway. This warning will appear again for each new version, because an unsigned program's reputation does not carry across releases. Verify your download against the published SHA-256 checksum if you want certainty about what you received.
cargo build --release # both binaries
cargo run --release -p pdfce-gui -- path/to/file.pdf
cargo run --release -p pdfce-cli -- --helpRust toolchain version is pinned in rust-toolchain.toml. There are no
system dependencies to install; the GUI uses a software/OpenGL backend
rather than requiring a Vulkan/DX12 stack.
Four crates, and the split is load-bearing rather than cosmetic:
| Crate | Role |
|---|---|
pdfce-core | The PDF engine — parsing, the object model, editing, writing. Zero GUI or windowing dependencies. |
pdfce-render | Headless rasterizer. Also zero GUI dependencies. |
pdfce-cli | The scriptable shell. |
pdfce-gui | The desktop application (egui/eframe). |
Two invariants shape most decisions:
- GUI–core separation.
pdfce-coreandpdfce-rendernever gain a GUI dependency, which is what keeps an eventual WebAssembly build a shell-crate swap instead of a rewrite — and what makes the GUI and CLI two independent front ends over one engine. - Round-trip / minimal-diff editing. Objects pdfce did not logically touch are re-emitted byte-identically, or simply omitted under the default incremental save. Redaction is the one deliberate exception: it must genuinely remove covered content, not mask it.
Where the PDF standard is genuinely ambiguous — and it often is — pdfce does not pick silently. The choice becomes an operator setting with a documented default, reachable from File → Settings or from a plain-text file beside the program. Each one states what the standard leaves open, how well-founded the default is, and whether changing it affects the file or only the view.
| Doc | What's in it |
|---|---|
docs/FEATURES.md | What pdfce can do today, per surface. Start here. |
docs/ARCHITECTURE.md | Crate layout, data model, invariants, packaging, dated decision log. |
docs/ROADMAP.md | Pass-by-pass plan and history, with the full reasoning. Large. |
docs/decisions/ | Numbered decision records for the choices that needed one. |
docs/DEPENDENCIES.md | What each third-party package is for, by crate, and what pdfce implements itself instead. The purpose-shaped view THIRD_PARTY_LICENSES.md (generated, licence-shaped) can't give you. |
docs/LEGAL.md | Licensing posture, PDF-spec sourcing rules, test-corpus rules, dependency attribution. |
docs/PRIOR_ART.md | What existing crates and tools were adopted, what was reference-only, and why. |
docs/SESSION_LOG.md | Append-only development record. |
The documentation is unusually detailed on purpose: the project's
standing rule is that the docs are the logic and the code is the syntax
that enacts it. ROADMAP.md in particular is a working engineering
record, not a brochure.
cargo test --workspace
cargo clippy --workspace --all-targets -- -D warnings
cargo fmt --all --checkTest fixtures are synthetic and generated by committed scripts under
tools/. A larger corpus of third-party PDFs is used for differential
testing against pdfium, but it is not redistributed in this
repository.
This is a personal project developed in the open rather than a project seeking contributors, and it moves fast. Issues and observations are welcome; please do not be surprised if a large unsolicited pull request does not fit the direction. If you are considering one, open an issue first.
MIT — see LICENSE.
Third-party dependency licences are generated into
THIRD_PARTY_LICENSES.md by cargo-about and are all permissive; no
copyleft code is linked. pdfce deliberately does not use GPL/AGPL PDF
engines (MuPDF, Poppler, Ghostscript), which is why several things were
implemented from the specification rather than adapted from existing
code.