Is it safe to upload your file to a free online tool?

What an upload actually is

Your browser makes a request whose body is the bytes of the file. The server has to put those bytes somewhere in order to work on them, which means a temporary directory or an object store, and from that moment there are copies nobody asked for:

• The access log of whatever sits in front of the application, recording the request, its size, your IP address and the time.
• The application's own log, which usually records the filename, and sometimes more.
• Wherever the encrypted connection was terminated. If a CDN or a firewall service answers on the operator's behalf, that is where the bytes were last in the clear.
• The object store, plus whatever replicas it keeps for durability.
• The backup of the object store, taken on its own schedule, which is usually not the same schedule as the deletion.
• The error tracker, if the job failed. Crash reports routinely carry the request that caused them.

Which is what makes deleted after one hour a weaker statement than it reads as. It describes a job that runs over the primary store. It is not a property of the system, and it says nothing about the backup taken at three in the morning, the replica, the log line, or the copy a support engineer made while reproducing a bug. It is a promise about somebody's housekeeping, and the only person who can check it is the person doing it.

None of that requires anyone to be dishonest. It is the ordinary shape of a working web service, and a small operator running one cheaply usually has more of it, not less.

In some work, sending it is the event

Duties about confidential material are usually written about disclosure rather than about breach. Handing a client's contract, a patient's record or a colleague's personal data to a third party is a disclosure at the moment it is handed over, whether or not anything subsequently goes wrong. Whether that third party is careful is a separate question, and one you would have to be able to answer if asked: who they are, which country processes the file, who their own subprocessors are, what the retention really is.

In practice a free web tool gets used without any of that being asked, because dropping a PDF into a page does not feel like sending a document to a company, though it is the same act as emailing it to them. That is worth deciding on purpose, and it has to be decided before the upload, because afterwards there is nothing left to decide. This page cannot tell you what your obligations are and does not try; it only points out that the question is usually about the act rather than the outcome.

What a browser-only tool does differently

The difference is mechanical, not a stronger promise. A file input hands the page a File object once you choose a file. That object is a handle to bytes on your disk, and the page cannot read it until you pick it. To work on it the page calls file.arrayBuffer(), or the older FileReader, and gets the bytes into the tab's own memory. On this site CLEANROOM begins its work on a single line, var u8 = new Uint8Array(await file.arrayBuffer());, and everything after that is arithmetic on that array.

Nothing in that path builds a request. The ways bytes leave a page are fetch, XMLHttpRequest, a form submission and navigator.sendBeacon, and reading a local file uses none of them. The result comes back as a Blob handed to you through an object URL, which is also local. The consequence you can feel is that the tool keeps working with the network switched off, because there was nothing it needed the network for.

What browser-only tools are worse at

This is the part a page selling browser-only tools usually skips.

• The work happens on your machine. A slow laptop is a slow tool, and the tab is competing with everything else you have open.
• The file normally has to be in memory whole. Real limits from this site rather than hypothetical ones: MACROLENS refuses a file over about 96 MB instead of letting the tab die, PDFSIG refuses over about 128 MB because the entire file has to be present to hash its byte ranges, and CAPSULE caps a job at forty megabytes. A server with plenty of memory never has that conversation.
• Models have to be shipped to every visitor. SCRIBE downloads a speech model once, about 40 MB of program code, before it can transcribe anything, and VEIL pulls in a machine-learning runtime and a face detector. A server loads its model once, for everybody.
• Some work genuinely needs a server. Anything that compares your file against other people's, anything that needs a shared index, anything that has to still be there when you open a different device.
• There are plain gaps. This site has no OCR at all. X-RAY can tell you a PDF already carries an OCR text layer, but nothing here will make one. Most tools have no batch mode either.
• Running in the browser does not by itself mean nothing leaves. A page that loads its libraries from a public CDN tells that CDN your IP address and which page you were on, before any file is involved. This site moved every library and both models to its own origin for exactly that reason: the libraries are committed to the site and served from /lib/, each held to the SHA-256 of the published file, and the models come through /vendor/, fetched once by the site's own server.

How to check the claim instead of believing it

Runs in your browser is a claim, and a claim from a site you have not heard of is worth little on its own. Three checks, in ascending order of effort, none of which requires trusting the operator.

Watch the network. Open the developer tools with F12, choose Network, and tick Preserve log so nothing vanishes. Run the tool on a file big enough that an upload would be unmistakable, then sort by size. The page, the stylesheet and the scripts come down; your file does not go up, and filtering to Fetch and XHR should leave nothing at all. This is the check that catches an upload.

Turn the network off in the middle. Load the tool, disable the wifi, then do the work anyway. If the file was being sent somewhere, the job cannot finish. It takes ten seconds and it is much harder to fake than the first one.

Read the Content-Security-Policy. It arrives as a response header on the document request and is visible in the same panel. The directive that matters is connect-src: it lists every origin the page is permitted to open a network connection to, and the browser enforces it whatever the site says. This site sends:

A script here that tried to post your document to another domain would be blocked before the request left the machine. Be precise about what that does not cover, though: 'self' still permits a request back to this origin, which is exactly what the first check is for. And the one outside host is Cloudflare's page-view counter, which records a page address and a time and never sees a file. A content blocker stops it and nothing on the site breaks.

Where to check this site's own claim

/verify is the page for it. It walks the three checks above, and it also hashes the files your browser actually received, with crypto.subtle.digest('SHA-256', ...) over each one, so you get a list of digests for the code you were served rather than a published list you would have to take on trust. The useful thing to do with that list is compare it: run it on another machine, on another network, or ask somebody in another country to send you theirs. A site serving one build to people who check and another to everybody else does not survive the comparison.

/threat-model is the other half, and it is the more conservative document of the two. It states tool by tool what each one protects against and what it does not, and it is blunt about the boundary: client-side execution removes the server from the list of parties who can see your file. It does not remove a compromised machine, a browser extension with permission to read every page, or the person you send the result to afterwards.

To try the mechanism rather than read about it, /workbench takes a file, works out what it is, and offers the tools that apply, moving the file between them through your own browser's storage rather than a server. Run it with the network panel open and watch what does not happen.