Does an HTTPS padlock mean my file is private?

No. HTTPS encrypts the file in transit, so nobody between you and the server can read it. It says nothing about what the server does with the file once it arrives, how long it is kept, or who can see it there. A padlock and an upload are entirely compatible.

Can I do this test on a phone?

Not easily — mobile browsers do not expose developer tools. The offline test works everywhere though: load the page, switch on aeroplane mode, then try the tool. If it works, it is local. On iOS and Android that is the practical version of this check.

The tool downloaded a large file before working. Is that bad?

No, that is usually the opposite. Tools that process locally often need to fetch a WebAssembly codec or a machine-learning model first, which can be tens of megabytes. That is data coming to you. What matters is whether your file goes the other way afterwards.

What if a site says files are deleted after an hour?

Take it at face value and note what it concedes: the file was uploaded and stored. That is a different risk profile from a file that never left your device, and the promise is unverifiable from outside. Judge it on how sensitive the document is.

Is client-side processing always better?

For privacy, yes. For capability, no — some conversions need engines that cannot run in a browser, and a local tool that produces a worse result is not a win. The right question is whether the trade is disclosed before you make it.

How to tell whether an online tool is uploading your files

Every free file converter claims to respect your privacy, and the claims are unfalsifiable as written: "we delete files after one hour" cannot be checked, and "your files are safe" means nothing at all. But there is one claim you can verify yourself in under a minute — whether the file leaves your device in the first place. A tool that processes files in your browser makes no upload request, and a tool that uploads makes one you can see. The browser's developer tools show you which, on any site, without installing anything. The distinction matters because "we delete it later" and "we never had it" are different risks: one depends on a company's retention policy, breach history and jurisdiction, and the other does not exist.

The thirty-second version: watch the network

Open the tool's page. Press F12 (or Cmd+Option+I on a Mac) to open developer tools, and click the Network tab. Clear the list with the ⃠ button so you are only looking at what happens next. Now add your file and run the tool.

If the file is being uploaded you will see a new request appear — usually POST, often to a path with upload, convert or api in it — and the important part is the size column. An upload request carrying a 4 MB photo is roughly 4 MB. That size, next to a request that appeared the moment you pressed the button, is the whole test. If nothing appears, or only small requests for scripts, fonts and adverts do, the work happened on your machine.

Two things commonly confuse this. Analytics and advert requests fire constantly and are a few kilobytes each — size tells them apart from an upload immediately. And some tools fetch a large WebAssembly module or model file before processing; that is a download, not an upload, and the Network tab labels the direction. A large incoming file followed by no outgoing request is the signature of a tool doing the work locally.

The stronger test: pull the plug

The network test tells you what happened once. This one tells you what is possible at all. Load the tool's page and let it finish loading. Then turn off your Wi-Fi, or switch developer tools to Offline in the Network tab's throttling dropdown. Now use the tool.

If it still works, the processing is unambiguously local — there is nothing left for it to talk to. If it hangs, errors, or tells you the upload failed, the work was being done somewhere else. This test cannot be faked, which is what makes it worth more than any wording on a privacy page.

Every tool on this site except the ten server-side PDF conversions passes the offline test, and those ten are labelled on the tool before you use them. Run it here if you like; run it on the site you were about to use for your payslip, which matters more.

Reading the signals before you even upload

Some things are visible without opening any tooling. A tool that shows a progress bar during "uploading" is telling you what it does. A tool that produces a shareable download link rather than a file has necessarily stored your document somewhere addressable. A file size limit is a strong hint: browsers do not care how large your file is, so a 10 MB cap usually reflects what a server is willing to accept.

Speed is a weaker but real signal. Local processing starts instantly and scales with your machine; a converter that takes exactly the same time for a small file as a large one, or that queues you behind other users, is not running on your computer.

None of these are proof on their own — check the network. But they tell you which sites are worth checking.

When it actually matters

For a meme you are resizing, it does not. For the documents people most often run through free converters, it does: payslips and bank statements, passport and identity card scans, signed contracts, medical letters, tax filings, and photographs of documents taken for a visa or loan application. These carry exactly the identifiers used for account takeover and identity fraud.

The realistic risk is not usually that a company reads your file. It is that a copy of it exists on infrastructure you have no visibility into, governed by a retention policy you did not read, in a jurisdiction you did not choose, at a company whose future breach you cannot predict. Deletion promises are made in good faith and are still promises about the future.

There is also a narrower case worth naming: documents you are contractually or legally not allowed to disclose to a third party. Uploading a client's contract to a free converter can be a confidentiality breach regardless of what the converter does with it, because the disclosure happened at the upload.

What server-side processing legitimately looks like

Not every upload is a red flag. Some conversions genuinely cannot run in a browser — rebuilding an editable Word document from a PDF, running OCR over a scan, or rendering a live web page to PDF all need a document engine far too large to ship to a tab. A tool that does those things honestly will say so.

What separates an honest server tool from an evasive one is disclosure before the fact: it tells you the file will be sent, says what happens to it afterwards, and does not bury that in a policy page. The pattern to distrust is the one that claims everything is local while quietly uploading, because a site willing to be wrong about that is not a good candidate for your trust on retention either.

Last updated: 2026-08-07

Try it on our image compressor

Open the Network tab, compress a photo, and watch nothing leave.

Frequently asked questions

Does an HTTPS padlock mean my file is private?: No. HTTPS encrypts the file in transit, so nobody between you and the server can read it. It says nothing about what the server does with the file once it arrives, how long it is kept, or who can see it there. A padlock and an upload are entirely compatible.
Can I do this test on a phone?: Not easily — mobile browsers do not expose developer tools. The offline test works everywhere though: load the page, switch on aeroplane mode, then try the tool. If it works, it is local. On iOS and Android that is the practical version of this check.
The tool downloaded a large file before working. Is that bad?: No, that is usually the opposite. Tools that process locally often need to fetch a WebAssembly codec or a machine-learning model first, which can be tens of megabytes. That is data coming to you. What matters is whether your file goes the other way afterwards.
What if a site says files are deleted after an hour?: Take it at face value and note what it concedes: the file was uploaded and stored. That is a different risk profile from a file that never left your device, and the promise is unverifiable from outside. Judge it on how sensitive the document is.
Is client-side processing always better?: For privacy, yes. For capability, no — some conversions need engines that cannot run in a browser, and a local tool that produces a worse result is not a win. The right question is whether the trade is disclosed before you make it.