Security · By 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 Rust, runs locally, and drops the features attackers actually abuse, so the attack surface is small by construction, not by configuration.

Download for macOS Windows

~70%

~70% of serious security bugs in Chromium are memory-safety problems [C21, 2026-10-15]. Safe Rust rules out that class of bug.

SourceChromium memory-safety page

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)

Memory bugs in C/C++ parsers are a common source of critical exploit chains.

C++

Parser bugs can lead to use-after-free and buffer overflows.

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.

On by default

Ships the full Acrobat JavaScript engine.

JavaScript interpreter

A JavaScript interpreter (QuickJS) is in the binary for XFA form calculations. Scripts from documents are not executed.

Image decoders (TIFF / JBIG2 / JPEG2000)

Zero-click exploits (e.g. FORCEDENTRY) abused JBIG2 overflows.

Complex C++ codecs

Large, intricate native codecs widen the attack surface.

Safe-Rust decoders

hayro-jbig2 / hayro-jpeg2000, with #![forbid(unsafe_code)].

Font parsing

Embedded fonts carry executable byte-code, a classic vector.

C++ CoolType

Font parsing runs through a historically targeted C++ stack.

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.

XFA + FormCalc

Full dynamic forms with live FormCalc scripting.

Rendered, no scripting

XFA is rendered and flattened, but scripting is disabled.

Attachments

Stops a PDF silently dropping and running malware.

Auto-extract

Can extract embedded files automatically.

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.

Runs on open

Document actions can fire the moment a file is opened.

Inert

All document actions are ignored.

Network egress & privacy

Prevents documents "phoning home" to exfiltrate data.

Online-first

OCSP, form-submit, cloud and telemetry by design.

No network path

Document content never goes over the network. The PDF engine has no path to an HTTP client.

DoS & resource quotas

Protects against zip-bombs and infinite recursion.

Runtime guards

Has guards but can crash on huge nesting.

Hard engine limits

Hard limits apply to file size, decompressed stream size, object nesting depth, and image size.

IPC bridge & WebView

Even an XSS in the UI can't read or write files.

n/a

Native C++ UI, no web bridge.

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.

Strong

AppContainer / Protected Mode sandboxing.

Medium

macOS App Sandbox; a standard process on Windows.

Digital signatures

Shadow Attacks let attackers change visible content without breaking the signature.

Broad, history of bypass

Wide support but historically prone to Shadow Attacks.

Strict Rust crypto

pdf-sign: modern CMS / PKCS12.

Higher riskCaveatReduced riskNot applicable

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 Rust, whose safe subset rules out that class of memory bug at the source. Reducing risk at the source beats containing it after the fact.

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 does not execute scripts found in documents. Opening a file does just that.

Privacy in a cloud age

PDF tools can contact the network through OCSP checks, cloud storage, form submission and telemetry. Each is a channel a document can use to phone home. PDFluent is offline-first: document content never goes over the network, and the PDF engine has no path to an HTTP client. What you process stays on your machine.

Where your files go

Cloud-based PDF tools

Your document is uploaded to a server you don't control before you can work on it.

Your deviceRemote server

PDFluent

Every operation runs on your machine. There is no upload step, because there is nowhere to upload to.

Your device: stays here

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).

Not executed

Document JavaScript

Inert

Automatic actions

None

HTTP client (PDF engine)

Hard engine limits

Off

Tauri global

A PDF editor that earns its trust.

Free for everyone, including at work. Runs entirely on your machine. No account, no cloud, and no telemetry unless you switch on crash reports yourself.