Verify it yourself
Your documents never leave your machine. That is the claim, and a claim is worth less than a test. Below is how to run the test, what you should see, and where checking from the outside stops working.
How do I test this on macOS?
Use Little Snitch, or run a packet capture from the terminal. Start the capture, then open a PDF, edit some text, save the file and export it. Watch the log while you do it. The capture shows you which connections are opened and how much crosses them; it will not show you what is inside them, because they are TLS.
sudo tcpdump -i any -n 'tcp port 443 or tcp port 80'Those four actions produce nothing. If you leave the app running you will see one connection to pdfluent.com a few seconds after launch — that is the update check, and it is described below. Activity Monitor's Network tab is a cruder version of the same test: it counts bytes per process, so the counter for PDFluent should not move while you work.
How do I test this on Windows?
Use Fiddler or Wireshark. Same four actions: open, edit, save, export. Fiddler will show you the decrypted HTTPS, which is the more useful view here, because it means you are not taking our word for what is inside the one connection you do see. Editing and saving produce no traffic. The update check shortly after launch is the only thing that appears.
What connections does the app make?
- When:
- About five seconds after launch, and when you pick Check for updates.
- Carries:
- An HTTP GET. Anything it downloads is signature-checked against a key compiled into the app.
- Stopping it:
- No off switch in the app today. A firewall rule is the way.
- When:
- Only if you turn reports on in Settings and then submit one.
- Carries:
- A crash, bug or feedback report. Messages and stack traces are scrubbed first.
- Stopping it:
- Off by default. The switch is in Settings.
- When:
- Only when you click a link in the app.
- Carries:
- Nothing from the app. Your browser makes the request, not PDFluent.
- Stopping it:
- Do not click the link.
That is the complete list. Document content is in none of them.
What the test looks like when we run it
Run on 19 August 2026, against the signed, notarised build from the release DMG — PDFluent 1.0.0-beta.21, the same file the download page serves. A document was opened, edited, saved and exported to Word while every socket owned by the app's process was recorded. The run lasted fifteen minutes.
| First seen | Address | Port | Resolves to |
|---|---|---|---|
| 15:18:57 | 2606:4700:3034::ac43:b5cb | 443 | pdfluent.com |
That is the whole table. One connection, five seconds after launch, to pdfluent.com — the update check. Nothing during the edit, nothing on save, nothing on export. The raw log and the full report are here rather than summarised, because a summary is the part you would have to take on faith.
One thing to be straight about: this run used lsof, polled twice a second, not tcpdump. It records which process owned every connection, which a packet capture alone cannot tell you. What it does not do is show what travelled inside that one connection — and neither would tcpdump, because the connection is TLS. Only a proxy you have deliberately trusted, like Fiddler with its own root certificate, can read inside it.
Why can’t the PDF engine access the network?
There is no code path from the PDF engine to the network. The one HTTP client compiled into the app arrives with the updater component, and the engine cannot reach it. The engine crates do carry optional HTTP clients — for cloud OCR, and for signature timestamping — and neither feature is switched on in the desktop build.
A JavaScript interpreter is compiled in. It is QuickJS, and it is there for XFA form calculations, not for scripts found in documents. Those do not run: it takes an environment variable, off by default, to enable them at all. With it on, the sandbox exposes two form values and nothing else — require, process and fetch throw. Automatic actions such as /OpenAction are inert either way.
Can I verify the source code was used?
You can watch the binary you downloaded. You cannot check that it was built from the source described here, because that source is not public. Nothing on this page closes that gap. Only reproducible builds or a third-party audit would, and neither exists yet.
So the honest summary is narrower than the headline: this page tells you how to observe the app you can actually run. That is a real test, and it is not the same as proof.