Verify a PDF Tool's Privacy Claims With DevTools in 5 Minutes

-- title: "Verify a PDF Tool's Privacy Claims With DevTools in 5 Minutes" description: "Stop trusting the marketing. Open the Network tab, run one merge, and see whether the file actually leaves your device. Full walkthrough with the common misreads." tags: ["privacy", "webdev", "devtools"] canonical_url: https://pdfmergenext.shop/blog/devtools-network-tab-privacy-guide "Files never leave your device" is the most common privacy claim in the PDF tools space, and the most untested. You do not need to believe it or distrust it, you can verify it in five minutes with the tools already in your browser. Step one: open the Network panel. Chrome or Edge, F12 or right-click → Inspect → Network tab. Clear the request history first, the static resources from page load will muddy your reading. This is the step most people skip. Step two: do one real operation. Merge a multi-MB PDF. Not a 0-byte file, those can get cached and skipped. Then scan the new requests from bottom to top for two signatures: multipart/form-data: the file went up as form data, red flag Binary PUT/POST of tens of KB or more: file content transferred, red flag Static resources only (js, css, png): normal, the file never touched the network Open any suspicious request and check the Payload or Request tab. If your filename or binary data appears in the body, it was uploaded. Step three: the offline test. Refresh, let it load, cut the network (turn off Wi-Fi, or tick Offline in the Network panel), merge again. If it completes, the processing is entirely local. This 30-second test is the most honest verification there is. The misreads. Seeing any request is not proof of upload, fonts and scripts are requests too. Watching only the Network tab misses WebSocket transfers, check the WS tab or the browser task manager's per-tab network usage. And 0-byte test files get cached, use a real PDF. Run this on any tool you use. Most "privacy-first" marketing fails at the first check.