Why ToPDF cannot see your documents (architecture, not policy)

Most privacy promises are behavioural: we could, but we won't. The stronger class is architectural: the system has no path for it. ToPDF is built in the second class, and the difference is worth understanding.

Follow the bytes

1. Your photo enters the browser tab via the file picker — an OS-mediated handoff to that tab only.
2. Every processing step runs in the tab's memory on your CPU.
3. The PDF is assembled in the tab and written to your storage by the browser's download machinery.

For your document to reach us, code would have to exist that uploads it — there is none, there's no server endpoint listening for any, and the site's security policy (visible in its headers) restricts where the page may connect at all. Absence of capability, not restraint.

How an outsider can check

• Offline test: full functionality in airplane mode — impossible for anything server-dependent. (Why that's proof.)
• Network inspection: DevTools shows every request; scans produce none. (Guide.)
• Delivery model: static files from a CDN — no application server exists that could receive documents.

What this buys you

No trust negotiation per document: the sensitive deed, the medical report, the passport — the architecture treats them identically because it never has them. Policies can change with ownership and time; the absence of an upload path is checkable today, by you, every time.

Frequently asked questions

Could a future update add uploading?

Any tool’s code can change — which is why verifiability matters more than promises. The offline and network tests remain available to anyone, any day; the architecture makes silent data collection a detectable regression rather than a hidden default.

What about the hosting provider?

It serves the app’s static files and sees ordinary web traffic — never document content, which travels nowhere. See the data inventory.