SecurityBy construction, not configuration
Security by design.
Not damage control.
Most PDF software adds locks after the fact. PDFluent removes the doors. The engine is written in memory-safe Rust, runs 100% locally, and drops the features attackers actually abuse — so the attack surface is small by construction, not by configuration.
~70%
~70% of severe security bugs are memory-safety flaws (Microsoft, Google) — Rust eliminates that entire class.
SOURCEMicrosoft Security Response Center·Google Chrome security
Attack surface · side by side
Where the risk actually lives
A feature-by-feature look at the parts of a PDF reader that attackers target — and how PDFluent's choices compare with a traditional C++ engine like Adobe Acrobat. Adobe-side points are general, historical industry facts.
Aspect
Adobe Acrobat
PDFluent
Memory safety (parser & core)
C/C++ parser bugs are the #1 source of critical exploit chains.
Adobe Acrobat
C++
Parser bugs can lead to use-after-free and buffer overflows.
PDFluent
Memory-safe Rust
Interpreter + heavy decoders forbid unsafe; the parser is safe Rust bar one audited unsafe (a self-referential cache).
JavaScript in PDF
PDF-JS is abused for heap spraying and phishing prompts.
Adobe Acrobat
On by default
Ships the full Acrobat JavaScript engine.
PDFluent
No JS engine
No scripting engine in the backend — document JS is absent.
Image decoders (TIFF / JBIG2 / JPEG2000)
Zero-click exploits (e.g. FORCEDENTRY) abused JBIG2 overflows.
Adobe Acrobat
Complex C++ codecs
Large, intricate native codecs widen the attack surface.
PDFluent
Safe-Rust decoders
hayro-jbig2 / hayro-jpeg2000 — #![forbid(unsafe_code)].
Font parsing
Embedded fonts carry executable byte-code — a classic vector.
Adobe Acrobat
C++ CoolType
Font parsing runs through a historically targeted C++ stack.
PDFluent
Safe-Rust parsing
pdf-font parses fonts in Rust and forbids unsafe.
Dynamic forms (XFA)
XFA is deprecated in PDF 2.0 and historically CVE-rich.
Adobe Acrobat
XFA + FormCalc
Full dynamic forms with live FormCalc scripting.
PDFluent
Rendered, no scripting
XFA is rendered and flattened, but scripting is disabled.
Attachments
Stops a PDF silently dropping and running malware.
Adobe Acrobat
Auto-extract
Can extract embedded files automatically.
PDFluent
Manual save only
Saved via an OS dialog; dangerous extensions are blocked.
Automatic actions (/OpenAction, /AA)
Opening a file should never trigger actions or network calls.
Adobe Acrobat
Runs on open
Document actions can fire the moment a file is opened.
PDFluent
Inert
All document actions are ignored.
Network egress & privacy
Prevents documents "phoning home" to exfiltrate data.
Adobe Acrobat
Online-first
OCSP, form-submit, cloud and telemetry by design.
PDFluent
Offline-first
No HTTP client in the backend.
DoS & resource quotas
Protects against zip-bombs and infinite recursion.
Adobe Acrobat
Runtime guards
Has guards but can crash on huge nesting.
PDFluent
Hard tested limits
500 MB file, 256 MB stream, 100-level depth, 256 MP images, XFA nesting 50, FormCalc 200.
IPC bridge & WebView
Even an XSS in the UI can't read or write files.
Adobe Acrobat
n/a
Native C++ UI — no web bridge.
PDFluent
Hardened Tauri IPC
withGlobalTauri off; strict CSP (object-src none, frame-ancestors none, form-action none); no ambient filesystem or shell rights.
Process sandboxing
Acrobat needs that shield because its C++ base is inherently unsafe; PDFluent reduces the risk at the source.
Adobe Acrobat
Strong
AppContainer / Protected Mode sandboxing.
PDFluent
Medium
macOS App Sandbox; on Windows/Linux a standard process.
Digital signatures
Shadow Attacks let attackers change visible content without breaking the signature.
Adobe Acrobat
Broad, history of bypass
Wide support but historically prone to Shadow Attacks.
PDFluent
Strict Rust crypto
pdf-sign — modern CMS / PKCS12.
Higher riskCaveatReduced riskNot applicable
01
The sandbox fallacy
A sandbox is a wall built around unsafe code. Acrobat needs a strong one precisely because its C++ core is memory-unsafe by construction. PDFluent takes the opposite route: the parser, interpreter and highest-risk decoders are written in memory-safe Rust, so an entire class of exploit never gets to the wall in the first place. Reducing risk at the source beats containing it after the fact.
02
Zero-click dangers
The most dangerous PDF exploits need no interaction at all — opening the file is enough. FORCEDENTRY abused a JBIG2 image decoder; others ride embedded fonts or automatic actions. PDFluent decodes images and fonts in safe Rust, ignores /OpenAction and /AA entirely, and ships no document-scripting engine. Opening a file does just that.
03
Privacy in a cloud age
Most modern PDF tools are online-first: OCSP checks, cloud storage, form-submit, telemetry. Every one of those is a channel a document can use to phone home. PDFluent is offline-first — there is no HTTP client in the backend, so the files you open have nowhere to send your data. What you process stays on your machine.
Hard guarantees
Limits you can verify, not promises you take on faith
These are enforced in the engine itself. The interpreter and the highest-risk decoders forbid unsafe code outright (#![forbid(unsafe_code)] in pdf-interpret, pdf-font, hayro-jbig2 and hayro-jpeg2000).
No engine
Document JavaScript
None
HTTP client (backend)
100 levels
Max object depth
A PDF editor that earns its trust.
Free for personal use. Runs entirely on your machine. No account, no cloud, no telemetry.