How to check if a file tool uploads your files

Many free PDF and image sites work the same way: your file is uploaded to a server, processed there, and offered back as a download. Some tools do the whole job inside the web page instead, so the file never leaves your computer. From the outside the two look identical. Both have a drop zone and a download button, and both may describe themselves as secure.

You can tell them apart in about five minutes with the developer tools built into your browser. This guide covers two tests, what an upload looks like when you see one, and what the tests cannot tell you.

Why it matters

Once a file is uploaded, what happens to it is a matter of policy: how long it is kept, who can reach it, where the servers are, and whether it is used for anything else. Those policies can be good, but you are trusting them.

When a page processes a file itself, it reads it through the browser's File API. The bytes are loaded into the page's memory on your device, changed by code running there (often WebAssembly), and handed back to you as a download. None of that needs a network connection, which is what the two tests check.

Test 1: watch the network while the tool works

Use a file you would not mind sharing, ideally a large one of 10 MB or more, so an upload is easy to spot.

1. Open the tool's page.
2. Open the developer tools with F12, or Ctrl+Shift+I on Windows and Linux, Cmd+Option+I on a Mac, and choose the Network tab.
3. Tick Preserve log in Chrome, or choose Persist Logs from the Network Monitor's settings menu in Firefox, so requests are kept if the page navigates. Then clear the list.
4. Add your file and run the tool until you have the result.
5. Read the requests that appeared. Sort them by size, and check the method column; in Chrome, right-click a column header to add Method if it is hidden.

What an upload looks like

• A POST or PUT request sent while the tool was working, usually of type fetch or XHR.
• A request body about as large as your file. Click the request and open Payload in Chrome or Request in Firefox: an upload is often sent as multipart/form-data with your file name in it.
• Large files are sometimes sent in chunks: a series of POST requests of a few megabytes each.
• A WebSocket connection with large messages going out. Select it and open Messages to see them.

What harmless traffic looks like

A page that works locally still makes requests, and a long list is not a warning sign on its own:

• GET requests for code. JavaScript files and .wasm modules. Tools for video, OCR or image recognition often download several megabytes of code or model data the first time you use them. Those are downloads to you: the size is in the response, not the request.
• Small analytics requests. POSTs of a few hundred bytes that count page views.
• Fonts, icons and images that the page itself uses.

The rule of thumb: look at what is sent, not what is received. A local tool's outgoing requests stay small however large your file is.

Test 2: run the tool offline

The second test is stronger, because it does not depend on reading the request list correctly.

1. Load the tool and run it once with any file. This makes the browser fetch every piece of code the tool loads on demand, such as an encoder or a language pack.
2. Go offline. In Chrome's Network tab, change the throttling menu (it usually says No throttling) to Offline. In any browser you can turn off Wi-Fi instead.
3. Run the tool again with a different file.

If you get a correct result with the network off, the processing happened on your device. If the tool stalls, shows an error or waits for a connection, it needed a server.

Keep the developer tools open when you go back online. A page could in principle hold data and send it later, and the request list would show that too.

A hint, not proof: the content security policy

Sites can send a Content-Security-Policy header that tells the browser which addresses the page's scripts may connect to, in its connect-src directive. You can read it on the first request in the Network tab, under the response headers.

It is a useful hint, but not proof:

• connect-src 'self' still allows uploads to the site's own server.
• A header named Content-Security-Policy-Report-Only only reports violations. It does not block anything.

Treat the policy as supporting evidence and rely on the two tests.

What these tests cannot tell you

• They cover one visit. A site can change its code tomorrow. If you handle sensitive files regularly, repeat the check now and then, or prefer tools whose source code is public.
• Browser extensions can read pages too. An extension allowed to read and change data on all sites can see the files you open in a page, and its traffic may not appear in the page's request list. Use a browser profile without extensions for sensitive work.
• Peer-to-peer connections are listed elsewhere. WebRTC traffic between browsers does not show up in the Network panel; Chrome lists active connections at chrome://webrtc-internals. A file tool has little reason to use it, but look there if you want to be thorough.
• Local is not always faster. A page that works on your device uses your processor and memory. Very large files can be slow on an older phone, where a server might have been quicker.

If a tool does upload

That is not automatically a problem. Before using it for anything sensitive, read the privacy policy and look for:

• A specific retention period, such as one hour, rather than "a reasonable time".
• Whether files are used for anything besides your request.
• Exceptions, such as documents kept longer for legal reasons.
• Where the servers are, if that matters for your work or your employer's rules.

How this site handles it

Every tool on Toolbench reads and writes files in the page. The code it needs, including encoders, OCR language data and image models, is loaded from the site itself, and your files are not sent anywhere. The security page lists the requests the site makes and the one outside link a tool offers. Its content security policy is still report-only, so it does not count as proof here either. You do not have to take any of this on trust: both tests work here too.

Sources

• File API, MDN Web Docs. developer.mozilla.org
• Network features reference, Chrome DevTools. developer.chrome.com
• Network Monitor, Firefox DevTools user docs. firefox-source-docs.mozilla.org
• CSP: connect-src, MDN Web Docs. developer.mozilla.org
• Content-Security-Policy-Report-Only, MDN Web Docs. developer.mozilla.org