Documents · PDF Toolkit
Verifying a PDF Tool Never Uploads Your File: Network Panel Walkthrough
· How it works
pdf privacy network-inspection
You do not have to trust a privacy claim; you can watch the network. This post shows how to open the browser's Network panel, run a PDF operation, and read the result, plus what a strict Content Security Policy tells you about third-party code.
Trust, but check — why 'nothing is uploaded' is a testable statement rather than a marketing line
“Nothing is uploaded” can be tested because an upload requires observable network activity from the page or its workers. A compliance review should use a harmless, distinctive test document rather than confidential material, then compare runtime requests with the source and automated network-isolation test in the repository.
One clean run proves behavior for that build, browser, consent state, and operation. It does not certify every future deployment or browser extension. Record the tested URL, date, operation, and request log. Precise evidence is more useful than a broad assurance that cannot be reproduced.
Opening the Network panel — where to find it in the major browsers and what to clear before you start
Open developer tools and select Network before choosing the test file. Chromium, Firefox, and Safari place it in their developer interfaces, though labels vary. Preserve the log only if you need navigation requests; otherwise clear it after the page and its static scripts have loaded to isolate the operation itself.
Keep all request types visible at first, including fetch, XHR, scripts, and workers. Disable neither cache nor analytics unless the test plan calls for those states. A consented production session can legitimately load disclosed Google analytics resources, so the task is to determine whether document bytes or identifying file fields enter a request.
Running the operation — merging or splitting a test PDF while the panel records, and what an upload would look like if one happened
Choose a synthetic PDF with recognizable harmless text and run merge, split, or another operation. Watch the request list from selection through completion and download. An upload would normally appear as a new fetch or XHR with a request body, multipart form data, or binary payload whose timing follows file selection or Run.
The toolkit should instead transfer bytes to a local Web Worker, which does not appear as a document request. PDF-to-image loads bundled pdf.js code from the same site when invoked and uses its worker for parsing; canvas encoding remains on the main thread. Code-resource loading is not equivalent to sending the selected PDF.
Reading the result — distinguishing the page's own static assets from a request carrying your file's bytes
Inspect new request URLs, methods, initiators, headers, and bodies. Static JavaScript, CSS, fonts, and same-origin worker modules support the page but do not contain the chosen bytes. Search request payloads for a distinctive test phrase or filename, while remembering that a binary upload may not render as readable text in every panel.
Also inspect timing. A request that began before selection cannot contain the later file. A download initiated from a Blob may show browser-internal behavior rather than a server response. The source confirms that result bytes are wrapped locally and passed to a shared Blob download helper, not fetched from an output URL.
Check loaded third-party code and consented production analytics rather than assuming none exists
The outline expects a strict policy proving no external script, font, or tag loads, but current privacy content allows consented analytics on the canonical production host. Check response headers and the actual initiator tree rather than asserting a policy outcome. Google analytics scripts are third-party code and are disclosed separately.
ToolAcre events use a closed field list that excludes PDF contents, filenames, pasted text, URLs, and exact file sizes. That design reduces exposure but does not make analytics requests disappear after consent. A correct report distinguishes “no request carries document bytes” from the false claim “the page makes no external request at all.”
Worked example — a full verification run on a multi-megabyte PDF, with the request list before, during and after
For a multi-megabyte test, clear the panel, choose the PDF, wait for the page count, run a split, download the output, and clear files. Mark requests that occur at each stage. The expected processing interval has worker messages and progress changes but no network entry containing the source document.
Repeat once with consent denied and once with consent granted on the production host if analytics behavior is in scope. Compare the logs. The document path should remain local in both cases, while analytics resource behavior may differ. Retain screenshots or a HAR only if the synthetic document contains no sensitive material.
What this does not cover — auditing the JavaScript itself, and why a network check proves behaviour rather than intent
Network inspection proves observed data movement, not developer intent, hidden behavior outside the tested path, or the safety of extensions and the operating system. Source inspection complements it: operation handlers call workers, renderers, Blob construction, ZIP creation, and the download helper rather than an upload API.
Automated isolation tests add repeatability but are still bounded by their scenarios. Review all offered operations when approval covers the whole toolkit, including image watermarking and conversion. Recheck after substantial deployment changes. A privacy assertion is strongest when runtime observation, implementation, tests, and published wording all agree.
The observed PDF operation should carry no file bytes, while disclosed analytics requests remain separate
The PDF Toolkit is designed so the selected file enters browser memory and local processing, not an application endpoint. A clear Network panel should show no request carrying the PDF during transformation. That is the narrow, defensible claim the walkthrough can verify.
Document disclosed analytics separately, record consent and host conditions, and avoid treating static resources as uploads. Then retain the evidence with the review. Verification is not a one-time trust ritual; it is a repeatable procedure that can catch a future regression precisely because the expected boundary is stated clearly. Testing more than one operation also guards against approving a local merge path while overlooking a different conversion branch with separate runtime dependencies.