“Your files never leave your device.”
You have read that sentence on a dozen file-conversion sites. It is sometimes true. It costs nothing to write when it is not, and there is no regulator checking.
The good news is that you do not have to take anyone’s word for it, ours included. A browser cannot upload a file without making a network request, and your browser will show you every network request it makes. The check takes about a minute and works on any site.
Here is how to do it.
The one-minute check
You will need a file you do not mind experimenting with, and a desktop browser. Chrome, Edge and Firefox all work the same way.
1. Open the tool’s page, but do not use it yet.
2. Open developer tools. F12, or Ctrl + Shift + I on Windows and Linux, Cmd + Option + I on a Mac. Click the Network tab.
3. Clear the log and start watching. There is a circle-with-a-slash icon to clear existing entries. The page has already loaded its scripts and images and you do not care about those — you care about what happens next.
4. Now use the tool. Select your file, run the conversion, download the result. Do the whole thing.
5. Read the log.
What you are looking for is any request that carries your file away. Specifically:
- Method. A
POSTorPUTsends data outward. AGETfetches something in. Sort or filter by method and look at the outbound ones first. - Size. This is the giveaway. If you fed the tool a 4 MB photo and there is a request whose request payload is roughly 4 MB, your photo went somewhere. Client-side tools produce no request even remotely that size.
- Type. Filter by
Fetch/XHRandDoc. That covers the ways a page sends data programmatically.
Click any suspicious request and look at the Payload or Request tab. If your file’s contents are in there, the claim is false. It is that blunt.
6. Try it offline. This is the strongest version of the test and it takes ten seconds. Load the tool’s page, then disconnect from the internet — turn off Wi-Fi, or tick “Offline” in the Network tab’s throttling dropdown. Now use the tool.
A genuinely client-side tool keeps working. It has everything it needs already. A tool that quietly uploads will hang, error, or produce nothing at all.
What you will see that is harmless
Not every network request is a betrayal, and if you go in expecting silence you will alarm yourself over nothing.
Library loading. Many client-side tools pull in a code library the first time you use a particular feature — a PDF engine, a ZIP builder. These are GET requests fetching a .js file to your browser. Our tools do this: the PDF toolkit fetches pdf-lib on demand, the archive export fetches JSZip, and so on, only when you use the feature that needs them. Data flowing in is not data flowing out.
Fonts, icons, stylesheets. Same category. Inbound GET requests, usually cached after the first visit.
Analytics. You will often see small requests to an analytics endpoint. These are worth knowing about — they are why the site knows a conversion happened — but they carry a few hundred bytes of event data, not your file. Size tells you which is which.
Service workers. A cached page may serve resources without a visible network request at all. That is the opposite of the problem you are checking for.
The signal is not “is there traffic.” It is is there outbound traffic proportional to my file’s size.
The second thing worth checking
A tool can be perfectly honest about not uploading and still leak in another way: what it downloads while you use it.
If a tool fetches a script from a third-party domain at the moment you press the button, that third party learns your IP address, roughly when you used the tool, and which page you were on. That is not your file, but it is not nothing.
In the Network tab, look at the Domain column. Requests to the tool’s own domain are self-contained. Requests to a content delivery network are common and generally benign. Requests to an ad network or a data broker while you are processing a document are a different conversation.
We load four libraries from a public CDN — pdf-lib, pdf.js, JSZip and a QR encoder — and only when a tool needs one. The barcode encoders and the EXIF parser we wrote from scratch, so the EXIF tool and the barcode generator make no external request at all. You can confirm both statements with the method above, and we would rather you did.
Doing this on a phone
Largely, you cannot, and it is worth saying so rather than pretending otherwise.
Mobile browsers do not expose a network inspector. On Android you can connect the phone to a computer and use Chrome’s remote debugging to get the full desktop Network tab against a page running on the handset; on iOS, Safari’s Web Inspector does the equivalent over a cable. Both work well and both are more setup than most people will do.
The practical answer is to run the check once on a desktop, against the same site you intend to use on your phone. It is the same code being served to both.
The offline test does work on mobile without any tooling, and it is the more valuable half anyway. Load the page, switch on airplane mode, use the tool. If it completes, nothing was uploaded — there was nowhere for the data to go.
What a privacy policy cannot tell you
A privacy policy describes intentions and obligations. It is worth reading, and it is a fundamentally different kind of evidence from what you have just gathered.
A policy can say files are deleted after an hour. It cannot demonstrate that the deletion job runs, that there are no backups, that a subprocessor is not retaining a copy, or that the policy was not rewritten last week. Policies also describe the operator’s intent, which is not the same as the outcome after a server is compromised.
The Network tab is different in kind. It does not tell you what someone intends to do with your file. It tells you whether your file moved. That is a matter of fact, observable from your own machine, and it does not require you to trust anybody — which is precisely why it is worth the minute.
Why so many tools do upload
Not out of malice, mostly. Because it is easier.
Server-side conversion means one implementation, running on hardware you control, in whatever language you like, with whatever libraries you like. Client-side means writing it in JavaScript, making it work in every browser, and keeping the download small enough that people do not leave.
Some things genuinely cannot be done in a browser at reasonable cost today — proper OCR, video transcoding, true PDF recompression. When a tool offers those, it is almost certainly using a server, and the honest ones say so.
We decided which tools to build partly on this basis. The list is shorter than it could be because we left out everything that would have required an upload. Optical character recognition, PDF-to-Word, video conversion — all deliberately absent, not overlooked.
What this actually buys you
A file that never leaves your device cannot be retained past its stated deletion window, cannot be exposed in a breach of a service you had forgotten using, cannot be handed over under a legal request, and cannot be quietly used as training data.
None of those risks are hypothetical, and none of them depend on the operator being dishonest. A well-meaning service with a good privacy policy and a compromised server has still leaked your document. The only file that is reliably safe is the one that was never sent.
That is the entire argument, and it only holds if the claim is true. So check it. On us as readily as on anyone else — if we ever break that promise, the Network tab will say so before we do.
Every tool on our tools page runs in your browser. Open the Network tab and confirm it.