Tools that upload your files

This list is empty, and it is empty because we went and checked rather than because we have not got round to the difficult formats yet. Six tools were on our plan marked "will have to upload". All six have since been resolved, and none of them ended up needing a server. If that ever changes, the tool will appear here, carry the upload badge on its own page, and explain what is sent before you choose a file.

The six that were supposed to need a server

Three were Office conversions: Word, Excel and PowerPoint to PDF. These are the standard example of "you need LibreOffice on a server for this", and we planned for exactly that. Then we built a browser implementation and measured it against the server pipeline. Layout retention came out at 99.7 per cent on résumé-style documents, 98.3 per cent on real-world Word files and 97.2 per cent on Traditional Chinese documents. Conversion took 13 to 353 milliseconds in the browser against 1.9 to 6.6 seconds server-side, before counting the upload and download. The server version was slower, not more capable.

One was PDF to PDF/A, and we are not building it. Writing the PDF/A declaration layer is straightforward; being actually conformant is not, and there is no usable PDF/A validator that runs in a browser. That means we could not verify our own output. Shipping a compliance feature we cannot prove is worse than not shipping it, because the whole value of PDF/A is that an archive will accept the file.

One was DWG to PDF, which we rescoped to DXF to PDF. Every DWG reader we evaluated is either GPL-licensed — incompatible with how this site is built and distributed — or commercial, with the web-deployable tier quoted at around six thousand US dollars for the first year. DXF is an openly documented interchange format with permissively licensed parsers, and every CAD package can export to it. A narrower tool that is honest about its input beats a broader one we cannot ship.

The last was EPUB to MOBI, which we deleted. Amazon completed its move away from MOBI on 18 March 2025, and Send to Kindle now accepts EPUB directly. The tool would have had search demand and no user benefit, which is the worst possible combination — it would exist purely to capture traffic.

Why publish a page with nothing on it

A privacy claim is only worth something if there is a way for it to be falsified. "We never upload your files" is easy to say and hard for a visitor to check across a site with dozens of tools. A page that promises to list every exception is a commitment with a cost: it means that when an exception appears, we have to write it down.

It also removes an easy temptation. Adding one server-side feature quietly, on a site whose whole identity is local processing, is the kind of decision that gets made because nobody would notice. Having a page whose only job is to notice makes that much harder.

So this page is not a placeholder waiting for content. Empty is the correct state, and if you are reading this, empty is still the current state.

What might still require uploading one day

Optical character recognition on large scanned documents is the closest remaining candidate. Small jobs run locally with WebAssembly, but accuracy across many languages currently favours server-side engines, and accuracy is the entire product in OCR.

Long video transcoding is technically possible in the browser and often impractical for a different reason: a phone will run out of memory or thermally throttle long before a file of several hundred megabytes is finished. That is a device limit rather than a browser limit, so a server would be solving a real problem rather than a licensing one.

PDF to editable Word is a case where the honest answer is that nobody does it well. A PDF stores positioned glyphs rather than paragraphs, so any converter is reverse-engineering structure that was never saved. Moving that guesswork to a server does not make the guesses better — which is why we would rather explain the limitation than ship a disappointment.

The rules we are committing to if it ever happens

It will appear on this page, with the specific reason it cannot be done locally. There will be no category of tool that quietly uploads while the site keeps advertising that it does not.

The tool's own page will carry the upload badge in the same place every other tool carries its badge, so the difference is visible before you choose a file rather than buried in a paragraph.

It will say what is sent, where it is processed, and how long it is kept, in specific terms rather than "temporarily". And it will be a separate, clearly marked tool — never an invisible server-side fallback inside a tool that claims to be local. A silent fallback is the failure mode that would make every other page on this site untrustworthy.

What to check if you are sceptical

Do not rely on this page alone. Open developer tools, switch to the Network tab, and run whatever tool you were about to use. If your file is being uploaded you will see a request roughly the size of your file leaving the browser.

The site also sends a Content-Security-Policy that limits network connections to its own origin, which you can read in the response headers of any page. And the offline test is the most convincing one available: load a tool, disconnect your network, reload, and convert. Server-side processing cannot survive that.