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

It depends much less on the tool's promises than on one fact: the moment you upload, the file is a copy on somebody else's computer, and every reassurance after that is about their housekeeping rather than about the system. For some documents that copy is itself the disclosure, before anything has gone wrong at all. Here is what an upload really involves, what a browser-only tool does differently in mechanism, what browser-only tools are worse at, and how to check the claim instead of believing it.

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 behind its own origin under /vendor/ for exactly that reason, and the code that does it states that its integrity check is a byte-length comparison, which is weaker than a hash.

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:

connect-src 'self' blob: data: https://cloudflareinsights.com

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.

What this is, and what it is not

A hash proves what reached you, not that it is safe. Hashing the files your browser received tells you what you were served, and lets you compare that with what somebody else was served. It says nothing about what the code does. For that, the files here are plain readable JavaScript on this origin and are not obfuscated, which is an afternoon of work rather than a one-minute check.

The offline test proves one run, not every run. A tool that finishes with the network off clearly did not need the network for that job. It does not prove that some other code path would never make a request. Combine it with the network panel and the policy header, which cover different failure modes.

The machine is not inside the boundary. None of this helps if the device has malware on it, or a browser extension with permission to read every page. An extension runs inside the page and sees more than any server would. The threat model page on this site says the same thing at more length.

There has been no third-party audit. This site is a single-operator product with no certification and no external review, and the verify page says so plainly. What is on offer is evidence a visitor can gather in a few minutes, which is a smaller claim than a badge and has the advantage of being checkable.

Nothing here is advice about what you are permitted to send. Whether a particular document may be handed to a third party is a question about your profession, your contracts and your jurisdiction. This page explains the mechanics so the decision is made with the facts in view.

Questions people ask

Is it safe to upload a confidential document to a free online converter?

It is a decision to hand a copy to whoever runs it. The file lands in their storage and, in the ordinary course of operating a service, in access logs, application logs, replicas and backups. If the document is one you would not email to a stranger, the upload is the same act, and it is worth making deliberately rather than by habit.

What does files are deleted after one hour actually mean?

That a job runs over the primary store on that schedule. It is a statement about housekeeping, not a property of the system, and it usually says nothing about the nightly backup, replicas, the log line that recorded the filename, or a copy made while debugging. It is also unverifiable from outside, which is the part that matters.

How can I tell whether a tool really runs in my browser?

Open the network panel with Preserve log on, run the tool with a large file and watch whether anything goes up. Then reload the page, turn the network off and do the work anyway. Then read the Content-Security-Policy header on the document and look at connect-src, which is the list of origins the browser will permit the page to contact at all.

Is a tool that runs in the browser always better?

No. The work happens on your machine, so it is bounded by your machine: large files have to fit in the tab's memory, heavy processing is slower, and any model has to be downloaded to you before it can run. Some jobs genuinely need a server, and for a file you would happily publish the question hardly arises.

Does HTTPS mean my upload is private?

It protects the file from other people on the network between you and the server. It does nothing about the recipient, who is the party you were worried about, and the connection is decrypted wherever it is terminated, which is often a CDN or firewall service in front of the actual application rather than the application itself.

Can this site see the files I open in it?

No, and the point of the verify page is that you should not take that on faith. The files are read by script in the tab, the browser is told by a Content-Security-Policy that this page may only connect back to this origin, and the tools finish their work with the network disconnected. Those three things are checkable in about a minute each.