How to Check Whether an Online Tool Uploads Your File

A privacy claim on a tool page is worth exactly as much as your ability to check it. The good news is that the check is short, needs no special software, and works on any browser. You are not looking for a promise. You are looking for one specific thing: a request that carries your file.

Test one: watch the bytes in the network panel

This is the primary method, and it takes about a minute. You are checking whether any request carries a payload about the size of your file.

1. Open the developer tools. Press F12, or use the browser menu and pick Developer tools. Switch to the Network tab.
2. Clear the list. Click the clear button, usually a circle with a line through it. This removes the page assets so only the requests from your file action remain.
3. Turn on Preserve log if you want a full picture. It keeps requests visible across a page reload, which helps when a tool navigates or refreshes mid-process.
4. Drop your file in and run the tool. Use a file with a distinctive size, ideally a few megabytes, so a matching request is obvious.
5. Watch the size column. Every request is listed with its transferred size. Read the largest one. If the biggest request is a script, a font or a small tracking call, the file never moved.
6. Click the largest request and read its details. The Headers, Payload and Size tabs tell you what was sent. A real upload appears as a request whose size is roughly your file size.

What you are looking for has a specific signature. An upload is usually a POST request to an endpoint such as /upload or /convert, and its size is close to the size of the file. If the request is a form, the content type is likely multipart/form-data. If the file is sent as raw bytes or base64, the content type is the file's own type, or the payload is a JSON body containing the data. In all three cases the size gives it away, and that is why the size column is the one to read first.

Test two: disconnect and keep working

The offline test answers a different question, and it is harder to fake. If the processing still completes with no network at all, then no server can be involved in the work.

1. Load the tool and run one file first. This caches the engine it needs, which is a normal download of code and is not your file.
2. Disconnect from the network. Turn off Wi-Fi, unplug the cable, or use the network throttling menu in the developer tools and set it to Offline.
3. Process another file without reloading the page. Do not refresh, because a reload needs to fetch the page itself and will fail for reasons that have nothing to do with uploading.
4. Watch the result. A local tool produces its output. A server-based tool fails, usually with a network error in its status line.

The order of those steps is the whole trick. If you disconnect first and reload, you are testing the page fetch, not the processing. And if you never ran the tool before going offline, a failure may just mean the engine was not cached yet. Run one job online, pull the connection, run a second job.

Test three: look at the domains and the security policy

Where a page sends data is as telling as how much. In the network panel you can sort or filter by domain, and the domains a local tool touches are boring: its own host, a font or script host, and possibly an analytics provider. A converter that runs on a server has to reach its own upload endpoint, and that endpoint usually appears on the same domain as the site.

A stricter signal is the Content-Security-Policy header, which you can read in the Headers tab of the main document request. A policy with a tight connect-src directive names the exact origins the page is allowed to call, which limits where a file could go even in theory. Its absence proves nothing, because many sites simply do not set one. Pair it with the network evidence rather than treating it as a test on its own.

What looks suspicious but is not

Most false alarms come from four kinds of request. Knowing them saves you from misreading a clean result as a leak.

• Analytics and tag managers. A page view is reported to a measurement service, which is why you see a script from an analytics domain. It carries the fact that a page loaded, not the contents of your document. This site loads Google Tag Manager, so you will see exactly this request.
• First-load engine downloads. A browser tool fetches its processing engine the first time you use it. That request is large, which makes it look like an upload, but it is the same for every visitor and does not change with your file. Size stays constant while your input changes.
• Fonts and icons. Typefaces and icon sprites are separate files and show up as their own requests. They are usually a few hundred kilobytes at most.
• Cross-origin isolation headers. Some WebAssembly tools require COOP and COEP headers for multi-threaded work. Seeing them is a sign that a real engine runs in the page, not a sign that your file is moving. The tools on this site use a single-threaded engine and do not need them.

The dividing line is simple. Code and page assets have sizes that stay the same no matter what you upload. Your file has a size that appears on the wire only if it is actually sent. Compare the total transferred bytes against the size of your input, and the answer is not ambiguous.

Where this method has limits

The tests above are strong, and they are not absolute. Being clear about the gaps is what makes the rest of the page trustworthy.

• Chunking hides individual rows, not the total. A tool could split a file into many small requests. Counting the total transferred bytes defeats that, which is why the size comparison matters more than any single row.
• A service worker can mask an offline failure. If a site caches its own pages, an offline reload may still work. The offline test is reliable only when you avoid reloading and rely on a completed job instead.
• Traffic can be encrypted and opaque. Over HTTPS you cannot read the contents of a request, only its size and destination. The size is enough to spot a file upload, but it will not tell you what a small request contains.
• Local does not automatically mean safe. Processing in the tab rules out an upload. It says nothing about other risks, such as a page that reads more of your disk in a later step. Check the specific claim being made rather than assuming good behaviour everywhere.
• Some tools genuinely need a server. Large models for background removal or generative enhancement do not fit a browser download budget, and those tools say so. The honest pattern is a page that tells you which of its features upload and which do not, as the Cloud AI section does here.

If you want the underlying explanation of why a tab can do this work at all, the companion guide on how browser-based file tools work walks through the engine, Canvas and File API layers. If you just want a tool to test, any page in the tool directory works, and Merge PDF is a good second subject because the input and output sizes are easy to compare.

Frequently asked questions