How to check whether a web tool really runs locally

Plenty of web tools say your file is processed locally and never uploaded. It is an easy claim to make and, until recently, a hard one for a visitor to check.

It is not hard. Your browser ships with the tool for it, and the check takes about thirty seconds. This page explains how — including on this site, which is the point.

The thirty-second check

1. Open the tool’s page, but do not add your file yet.
2. Press F12 — or right-click and choose Inspect — and select the Network tab.
3. Click the small ⃠ icon to clear the list.
4. Now add your file and run the tool.
5. Look at what appeared.

If the file is being uploaded, you will usually see a request with a POST or PUT method. In Chromium-based browsers, enable the Network table’s Transferred column and inspect the request’s Payload panel: the table’s Size column describes the response, not necessarily the request body. A file can also be split into several requests, compressed, encrypted, or sent over a persistent connection, so do not rely on one size match alone.

If the tool runs locally, you will see either nothing at all or requests for code, fonts, models, or public resources the tool says it needs. The decisive observation is that no request contains the file or its contents after you add it.

What you should expect to see, and what is fine

Some requests are normal and not uploads:

• Script and stylesheet files — the tool’s own code, loaded when the page loads
• A WebAssembly module — often several megabytes, for tools doing image or video work. This is code coming down, not your file going up. Check the direction: the size appears under a request for a .wasm file, not under a POST containing your data
• A machine learning model — same thing, sometimes 40–80 MB. Downloaded once, cached afterwards

What should make you stop:

• A POST or PUT request whose size matches your file
• A request to a domain that is not the site you are on, appearing at the moment you added the file
• Any request at all after you clicked the button, on a tool claiming to do everything locally

The offline test

There is a blunter version that requires no reading at all.

Load the page, then disconnect from the internet — turn off Wi-Fi, or use the Offline option in the Network tab. Now use the tool.

If it works with no connection, it cannot be uploading anything. There is nowhere for the bytes to go. This test cannot be faked and requires no interpretation.

The easiest tool to run this test on is one that needs no file at all. Open the microphone test, go offline, and speak: the meter still moves, the recording still plays back, and the WAV still downloads. Your operating system is showing a recording indicator the whole time, so you can see that audio is being captured — and the network panel shows that none of it is going anywhere.

A tool that fails this test is not necessarily uploading your file — it might simply need to fetch code it has not loaded yet. Reload the page first, let it settle, then go offline and try again.

Where the evidence stops

The panel answers one question completely and a neighboring question not at all, and the gap between those two is worth naming, because it is the whole reason this page exists.

When the bytes stay put, you have watched that happen. Nobody’s word is involved, no statement has to be believed, and the finding survives a change of management. But the moment a file does travel, the panel falls silent exactly where you would want it to keep talking. It records the request leaving. It has no view of what the machine at the far end does with what arrived.

That machine may be run immaculately — most of them are — and the questions a careful person would still want answered resolve out of sight. How long is the copy kept, and does a nightly backup outlive the deletion? Which employees can reach it, and under what approval? Which subcontractor holds the disk, and which of theirs? Every one of those is settled on the other side of the request, where no tool in your browser reaches. What remains is a published policy: a statement of intent, written by the operator, revisable whenever they like.

None of that is an accusation, and it should not be read as one. A service built around uploads has to move your file somewhere, since returning the result is the entire job. The distinction is not honest against dishonest operators. It is evidence against assurance — and only one of the two is something you can establish for yourself.

Why this matters more for some files than others

For a holiday photo, a server round trip is mostly inelegant. For other files it is a genuine disclosure:

• PDFs are contracts, invoices, medical letters and payslips
• CSV files hold customer lists, payroll and membership registers
• Photos carry GPS coordinates in their metadata by default, so uploading one shares where it was taken as well as what it shows — which is why removing EXIF data is the one job where a round trip defeats itself, and why the same argument applies to a document’s own properties
• Screenshots frequently contain someone else’s information along with your own. A local QR code scanner can read a square code from that image without sending the rest of the screen to a recognition service

Many organizations have policies against uploading documents to third-party services, which is exactly the situation a locally-run tool is for.

One task turns the whole question inside out, and it is worth naming because the contradiction is so complete. Marking part of a document for redaction is a declaration that it contains something which must not be seen — and the usual workflow starts by transmitting that document, unredacted and entire, to a stranger’s server so the passage can be removed at the other end. The disclosure happens before the protection. That is the one case where the check in this article is not a matter of taste, and it is why redacting a PDF belongs on the machine that already has the file.

Checking this site

Everything here works the same way, and we would rather you checked than took our word.

Open the Network tab, clear it, and use any tool on this site. You will see the page’s own code and — for the heavier tools — a WebAssembly module downloading. You will not see your file going anywhere, because there is no server to send it to. The site is static files on a CDN.

Pick something with a real file rather than a token one, since that is where a leak would show. Converting HEIC to JPG is a good subject: the photo is large, it carries location data, and the decoder is one of those WebAssembly modules, so you get to watch a genuine download happen and confirm that your picture is not part of it. For the opposite shape of test, the JSON formatter loads no module at all — paste a document, go offline first, and it still works.

There will eventually be one honest exception, and today there is not. Some planned tools will need to fetch a public URL that you type in, which necessarily involves a request. None of them is built yet, so right now every tool here passes the check above with nothing to explain away. When the first one ships it will say so on its own page. The distinction will be whose material it is: fetching a web address you supplied is not the same as uploading your private file, and nothing about those requests will be logged.

More on this

• Is CloudConvert safe? Yes, as far as anyone outside can tell. What the policy promises, what we measured on the front page, and the question no visitor is able to settle.
• Is Convertio safe? Yes, on all available evidence. Convertio makes the firmest deletion promise of the six — and firmer wording is still not something you can check.
• Is ezgif safe? Yes, on the evidence an outsider has. No account, no sign-up, a policy you can read in full — and one hour on the clock. What that hour covers.
• Is FreeConvert safe? Yes, on all the evidence a visitor can reach. But its policy keeps two deletion clocks — eight hours, three years — and only one of them is your file.
• Is iLovePDF safe? Yes, on the available evidence. iLovePDF promises deletion in two hours, with an exception. We read the policy to find where that promise stops.
• Is Smallpdf safe? Yes, on the available evidence. But the one-hour deletion figure everyone quotes is written for account holders, and most of its visitors are not one.