Does this program
send my files anywhere?

You installed a PDF tool and now you are about to open a contract in it. This page is the four checks worth doing first, with the command for each. They work on any Windows program. Nothing here asks you to trust a vendor, and that includes the vendor of this site.

Written for Windows 10 and 11. About 15 minutes if you do all four.

The short version

  • If you have 60 seconds: do check 1. Block the program from the network. If it still does everything you need, the question is answered for practical purposes.
  • If the source is shipped: do check 3. It is the only one that shows intent rather than capability.
  • If neither is available and the file matters: run it in a virtual machine with the network disconnected. That is not paranoia, it is the only definitive test.

1. Block its outbound traffic, then use it normally

Windows Firewall lets you block one executable by path. Do that before you open anything, then use the program the way you normally would. Anything that quietly stops working was talking to a server.

New-NetFirewallRule -DisplayName "block this tool" -Direction Outbound `
  -Program "C:\path\to\tool.exe" -Action Block

Remove the rule when you are done, or it will keep blocking after you uninstall:

Remove-NetFirewallRule -DisplayName "block this tool"

What this proves: whether the program still delivers its core function with no route out. What it does not prove: it only covers that one executable. A program that hands the work to a second process, or that loads a DLL which does the network call, gets around a per-path rule. Watch for a new tool.exe child process, or check the Network tab of Resource Monitor while it runs.

2. Read the strings inside the binary

Any program that uploads has a hostname or an IP compiled into it somewhere. Compilers tend to leave those as readable text. This extracts every URL-shaped string from the file, in both the 8-bit and the 16-bit encodings Windows binaries use:

$b = [IO.File]::ReadAllBytes("C:\path\to\tool.exe")
foreach ($enc in [Text.Encoding]::ASCII, [Text.Encoding]::Unicode) {
  $s = $enc.GetString($b)
  [regex]::Matches($s, "https?://[\w\.\-]+") | ForEach-Object { $_.Value }
} | Sort-Object -Unique

Expect noise: licence URLs, XML namespaces, the project homepage. What you are looking for is a host you do not recognise, or the vendor's own domain paired with a path like /api/, /upload, /licence, /telemetry.

What this proves: the absence of a domain rules out the lazy version of the trick. What it does not prove: anything at all about a hostile vendor. A hostname can be built at runtime from pieces, encrypted in a resource blob, hidden in a compressed packer section, or fetched from a config file. A clean scan means "no obvious collector", not "no collector".

3. Read the imports in the shipped source

If the download includes source, this is the highest-value check, because it shows what the author wrote rather than what survived packaging. Point it at the folder:

Select-String -Path .\*.py -Pattern `
  "import (socket|urllib|http|requests|httpx|ssl|ftplib|smtplib)|from (socket|urllib|http|requests)"

Several files will probably match nothing. The interesting ones are the matches: open them and read the call site. A single socket import that resolves the local hostname is not the same as a requests.post with a file handle in it. Judge the call, not the import list.

What this proves: what the code says it does, which is why it beats scanning a compiled file. What it does not prove: that the binary was built from that source. PyInstaller output is not byte-reproducible, so a shipped binary and a shipped source folder can differ without either one being dishonest. If you need that link closed, build it yourself from the source and use your build.

4. Hash the file, then check who else says that hash

certutil -hashfile "C:\path\to\tool.exe" SHA256

A hash published only on the vendor's own download page is close to useless: whoever can replace the file can replace the hash. It becomes useful when the same value appears somewhere the vendor cannot quietly edit, for example a public git commit with a date on it, or a second site you reached independently.

What this proves: the file you have is the file that was published at that moment. What it does not prove: that the file is harmless. A hash is an identity check, not a safety check, and an unsigned installer and a signed one can both be malicious. Signing tells you who built it; it does not tell you what it does.

What none of the four can tell you

Every check above looks for behaviour that has to be visible somewhere: a route out, a hostname, an import, a matching hash. A determined author can defeat all four. So the honest summary is that this is a set of cheap filters for the ordinary case - a tool that wants to upsell you a cloud account - not a security audit.

If the document is worth more than the tool, the cheap filters are not enough. Use a virtual machine with no network adapter, or a machine that has never had one, and copy the output out by hand.

We ran these on our own file

All four checks above are the ones applied to the executable this site sells, and the raw output of each is published, including the parts that look bad:

  • /verify - checksums, the string scan of the 41.9 MB binary, the import scan of the source inside the zip, and a section headed "what this page cannot prove".
  • /integrity.json - the same numbers as JSON, so you can diff them against your own run instead of reading a table.
  • the public repository - the same source, so the version inside the zip can be compared with something dated.

Two results from that run are worth stating plainly, because both were mistakes on this site before they were corrected. The binary does contain one domain, schemas.microsoft.com, which is an XML namespace in the Windows manifest and is never contacted. And an earlier version of the product page claimed the MCP mode opens no port at all; the binary does have an opt-in HTTP transport that binds 127.0.0.1. The claim was narrowed rather than deleted.

If you would rather not do any of this

Reasonable. Then the rule is simpler: do not put a document you cannot afford to lose into a program you cannot check, signed or not. Use the tool that comes with the operating system, or one whose source you can read, and accept the features you give up.