Why uploading is the risk to understand
Many online file tools work by sending your document, photo or video to a server, processing it there and sending the result back. That copy exists outside your device for at least a short time, may pass through other services, and is governed by a retention policy that few people read. For a holiday photo this may not matter; for a contract, an identity document, a medical report or a video of children it does. A tool that processes the file inside your browser avoids that copy altogether. This guide lets you verify which kind of tool you are using instead of trusting a sentence on a home page.
Watch the Network tab while the tool works
Open the developer tools of your browser: F12 or Ctrl+Shift+I on Windows and Linux, Cmd+Option+I on a Mac. Choose the Network tab and clear the list. Then load a small test file and run the tool. A server-side tool shows a request, usually POST or PUT, whose size is close to your file’s size, often to a domain that is not the site you opened. A browser-side tool shows no such request: you may see none at all, or only small requests for scripts that were needed earlier. Use a harmless test file first, so you learn what normal looks like before handling something private.
Disconnect and run the tool again
A second test needs no technical knowledge. Load the page, then switch on airplane mode or disconnect from Wi-Fi, and use the tool. If it still produces a result, the work is happening on your device, because nothing could have been sent. In Snipshed the main result keeps working offline; some previews, such as a PDF page preview, may need a resource that had not loaded yet. If a tool stops with a connection error the moment you press the button, it was relying on a server. Reconnect afterwards, and remember that a download you saved stays on your device either way.
2 PDF → 5 0 upload requests
Read the promise and know what a test cannot prove
A sentence such as files are deleted after an hour usually means the file was uploaded and stored for that time. A phrase like processed in your browser is better, but only a test confirms it. Even then, a test proves what happened in that session; it cannot prove what an updated page might do later, and it says nothing about browser extensions, which can read the pages you open. Hosting still receives ordinary technical data, such as the address that requested the page, but not your file. Check the privacy page of any tool for these details and be suspicious of vague wording.
Habits for sensitive documents
Work on a copy and keep the original untouched. Remove information you do not need to share: metadata from images and PDFs, irrelevant pages, the sound of a video. Use a private window without extensions when the material is delicate, and close the tab when you finish so temporary results are released. Check the saved file in the application that will receive it. For passwords and tokens, prefer tools that generate or decode them locally, and never paste live production secrets anywhere you have not verified. The few minutes spent testing a tool once are cheaper than a leaked document.
A two-minute verification
Download the two sample PDFs and open Merge PDF. Open your browser’s developer tools, select the Network tab and clear it. Add the two sample files, process them and watch the list: no request should carry the files. Then switch on airplane mode, clear the tool, add the files again and merge once more. Finally compare both results.
2 PDF → 5 0 upload requests
You see no request whose size matches the PDFs, and the merged result appears even without a connection. The merged file contains five pages.
If you see a large request after pressing the button on any tool, treat it as an upload. Repeat the test with another file type, such as an image in Remove image metadata. Note what you observed and the date, because pages and policies change.