Tools that never upload your files

Every file tool on this site is accounted for on this page. Not most of them — all of them. Each one does its work inside the browser tab you are reading this in: your file is read from your disk by your own browser, processed by your own processor, and written back to your own downloads folder. It is not transmitted to us at any point, and the important part of that sentence is that you do not have to take our word for it.

How this is actually enforced

Every page on this site is served with a Content-Security-Policy header. The part that matters is the connect-src directive, which lists the origins this page is permitted to open network connections to. Ours reads: connect-src 'self' blob:.

There is no external origin in that list. Not an analytics host, not a CDN, not a storage bucket. 'self' means this site itself; blob: means data the page created in your own memory, such as the converted file it is about to hand you for download. Because the list is exhaustive, a page served with this header cannot open a connection to anywhere else, whatever its scripts try to do.

That restriction is enforced by your browser, not by our code. If a script on one of these pages tried to POST your document somewhere, the browser would refuse to make the connection and log a violation in the console. The connection is refused before anything is sent, so the claim is not that we choose not to transmit your file — it is that not one byte of it can leave this machine. The guarantee therefore does not depend on us being careful, or on us staying honest after a change of ownership. It depends on a mechanism you already trust and that runs on your side.

This is a deliberately narrower claim than "you will not find any third-party address anywhere in the page source", and it is narrower because that version is not always true. Our CDN inserts its own analytics script tag into a small number of responses, and we will name the exact case below rather than let you find it yourself. When it happens, the browser blocks that script under the same connect-src rule before any request is made, so no data leaves — which is exactly why we would rather stake the promise on the mechanism than on the appearance of the markup. The mechanism holds in every case; the appearance does not.

How to verify it yourself in under a minute

Open any tool on this site, press F12 to open your browser developer tools, and switch to the Network tab. Click the clear button so the list is empty, then choose a file and run the conversion. Now read the list. Every row will be an address on this site: the page, the stylesheet, the JavaScript, and for some tools a WebAssembly module. Count the rows that point at any other host — the number you are looking for is zero. Sorting by size is the fastest version of the same check, because a row carrying your file would have to be roughly the size of your file, and there is no such row.

The stronger test is to disconnect from the network entirely. Load the tool once with a connection, then turn off Wi-Fi and reload. The page still works and still converts, because the code needed to do the job is already on your machine. Software that had been quietly uploading your file could not possibly behave that way.

You can also inspect the policy directly: in the Network tab, click the request for the page itself and read the response headers. The Content-Security-Policy is right there, and it is the same for every visitor. If you want to see the enforcement rather than just the header, open the Console tab as well — a blocked request appears there as a policy violation naming the address that was refused.

Why the usual sites cannot make this promise

Most well-known converters run the conversion on their own servers. That is a legitimate engineering choice — it lets them support formats a browser cannot handle, such as anything requiring a full office suite. But it has consequences that follow automatically from the architecture rather than from anybody's intentions.

Server processing costs money per file, which is why those sites cap free file sizes, limit tasks per hour, and add watermarks. Your file has to exist on their disk for some period, which is why their terms specify a retention window. The result is usually behind a URL that works for anyone who has it. And because a copy of your file has left your control, you now have to trust their retention policy, their access controls and their breach history.

None of those trade-offs apply to the tools on this page, because the file never leaves. That is also why there is no size cap, no hourly quota, no account and no watermark here: processing costs us nothing, so there is nothing to ration.

It is worth being precise about the causation, because it runs the opposite way to how it is usually presented. The server is not there because the conversion demands it. The server is there because server cost is what makes a paid tier necessary — and a free tier that has to be rationed is what makes the paid tier look attractive. Local processing removes the cost, and with it the entire reason to ration anything.

The hardest case we could find still did not need a server

The obvious objection to all of this is that browser-based conversion only works for easy formats, and that the difficult ones genuinely require server software. We had assumed that too. Office documents were the specific case: turning a Word, Excel or PowerPoint file into a PDF with faithful layout is usually described as needing a full office engine such as LibreOffice, which cannot run in a browser tab.

So we built it and measured it before deciding. Layout retention came out at 99.7 per cent on résumé-style documents, 98.3 per cent on real-world Word files collected in the wild, and 97.2 per cent on Traditional Chinese documents — the case we expected to fail, because it depends on font substitution and line-breaking rules rather than on simple geometry.

The speed result was the surprise. In-browser conversion completed in 13 to 353 milliseconds depending on the document. The server-side LibreOffice pipeline it was compared against took 1.9 to 6.6 seconds for the same files, before adding the time to upload the document and download the result. Local was not a compromise that traded speed for privacy; it was faster by a wide margin, because it never pays for a round trip or waits in a queue.

That measurement is why this page can say "all of them" rather than "most of them". The conclusion we drew from it is the one stated above: the industry uses servers for these conversions because of how the industry is funded, not because the browser cannot do the work.

Three separate things you can check

First, the mechanism. The Content-Security-Policy header on every page lists no external origin in connect-src, and your browser is what enforces it, refusing any outbound connection before it is made. This is the only one of the three that does not depend on trusting us at all, and it is the one the promise on this page is staked on — not on what the markup looks like, which is a weaker thing to check and, as the exception described below shows, not always true.

Second, the comparison. Open the privacy policy or terms of any well known converter and look for the retention window and the licence-to-process clause. They are not hidden; they are simply the necessary consequence of the file being on someone else's disk. Then look for the equivalent clause here, and note that there is nothing for it to describe.

Third, the measurements above. They are the reason we can rule out the "but the hard formats need a server" argument rather than just asserting it.

Where the boundary is

Two tools on this site do need the network, and they are named individually in the list of exceptions above rather than left for you to discover: finding your public IP address, and measuring your connection speed. Both are impossible to do locally — your public address is by definition what a remote server sees, and bandwidth can only be measured against something that sends and receives data. Neither has a file input, so neither can upload a document even in principle.

Those two carry a different badge and have their own honest explanation. We would rather state the boundary than stretch a claim until it stops being checkable. A privacy promise with unstated exceptions is worse than one with a clearly drawn edge — which is why the exception list on this page is generated from the same data that decides which badge each tool page displays, and cannot drift out of step with it.

There is one more exception, and it is about the page source rather than about any tool. Our CDN inserts an analytics script tag from static.cloudflareinsights.com into HTML it is allowed to rewrite. We suppress that on every page of this site by asking intermediaries not to modify the response body, and it works: view the source of any tool page and that address is not there. The suppression does not reach two responses. The first is the "page not found" response that the hosting platform generates for an address that does not exist on this site, because the platform replaces the relevant header with its own. The second is one deliberately unsuppressed page we keep as a permanent test target, so that our own monitoring always has a working example to compare against — if we removed it, the check that watches for this script would pass forever and would no longer be able to detect anything.

What that exception does not change is the guarantee. Both of those responses still carry the same Content-Security-Policy, so the browser refuses to load the script and no request is made to that address. You can confirm it on the spot: type an address on this site that does not exist, open the Console tab, and you will see the policy violation naming a script that was refused. That is the mechanism working, not failing. We are telling you about it because a claim you can disprove by viewing source is a bad claim to make, even when the underlying promise — that your files are not transmitted — is intact.