Skip to content
files.co

Why editing PDFs in your browser beats the cloud

Cloud PDF tools upload your file to a server. files.co edits it inside the browser with WebAssembly, so the file never leaves your device. Here's the difference.

AG Antonia González · June 18, 2026 · 6 min read

There are two ways to edit a PDF online, and they look almost identical. You drag a file in, you click a button, you get a result. The interface smiles at you the same way in both cases. What changes is where your file goes the moment you let go of it.

With most online PDF tools, your file goes on a trip. With files.co, it doesn’t go anywhere. That single difference is the whole article, but it’s worth understanding why it’s structural and not just a promise on a marketing page.

What actually happens when you upload to a cloud service

When you use a typical cloud PDF tool, “upload” is not a metaphor. Your file is copied, byte for byte, from your device across the internet to a server you’ve never seen, in a data center you can’t point to on a map. Then the processing happens there, and the result is sent back.

That trip has consequences, whether or not anyone has bad intentions:

  • The file lands on their servers. Even briefly, your document now exists on a machine you don’t control.
  • Retention is a policy, not a fact. “We delete files after one hour” is a sentence in a document. It is not something you can observe or enforce. You’re trusting a timer you can’t see.
  • Logs remember more than files. Even if the PDF is deleted, metadata tends to linger: filename, size, your IP address, timestamps, sometimes the page count. Logs are sticky by design.
  • Third parties join the party. Many services run on infrastructure they rent, with sub-processors, CDNs, and analytics in the mix. Your file’s trip may have more passengers than you think.

None of this requires malice. A breach, a misconfigured bucket, an overly curious backup, a subpoena, or a sloppy acquisition is enough. Once the file has left your machine, you are trusting a chain of people and systems to behave. That trust might be well placed. But it is still trust, and trust is exactly the thing privacy is supposed to remove from the equation.

How files.co does it: the file never leaves

files.co runs the PDF engine inside your browser using WebAssembly. WebAssembly is a fast, low-level runtime that ships with every modern browser, and it lets us run real document-processing code on your own device, locally, at near-native speed.

So when you merge, split, compress, or convert a PDF on files.co, here’s the actual sequence:

  1. You pick a file. The browser reads it into local memory on your machine.
  2. The WebAssembly engine, already loaded in the page, does the work right there.
  3. You download the result, which was generated on your device.

There is no step where the file is sent to us, because there is no “us” in the middle. The server’s job ends when it hands your browser the app. After that, processing is local. We can’t retain a file we never received, and we can’t log the contents of a document that never crossed the network.

This isn’t a smaller, kinder version of uploading. It’s a different architecture entirely.

Privacy by policy vs. privacy by architecture

Here is the distinction that matters most.

Privacy by policy means a company receives your data and then promises to behave: to delete it, not to sell it, not to peek. The protection is a rule, and rules can be changed, misread, ignored, or broken. The capability to misuse your file exists; you’re trusting that it won’t be used.

Privacy by architecture means the company is structurally unable to misuse your file, because it never gets the file in the first place. There’s nothing to delete, nothing to leak, nothing to subpoena. The protection isn’t a promise about behavior; it’s a property of how the thing is built.

A good policy is a locked door. A good architecture is not building the room. files.co is the second kind.

Don’t trust us, verify

The best part of privacy by architecture is that you don’t have to take our word for it. You can watch the file not leave, with tools already on your computer.

  1. Open files.co and press F12 (or right-click anywhere and choose Inspect) to open DevTools.
  2. Click the Network tab. This shows every request your browser makes to the internet.
  3. Tick Preserve log so nothing disappears, then do a real task: merge, compress, or convert a PDF.
  4. Watch the list. You’ll see the page assets load — scripts, the WebAssembly module, styling. What you will not see is a request uploading your PDF. No POST carrying your document, no megabytes leaving on the wire.

If you want to be extra thorough, do the whole thing, then turn off your Wi-Fi and run another conversion. It still works, because everything needed is already on your device. A cloud tool would simply stop.

The bottom line

Cloud PDF editors ask you to send your document away and trust the round trip. files.co keeps the document where it belongs: on your machine, from start to finish, processed locally by WebAssembly. Zero uploads, and we mean that literally — not as a slogan you have to believe, but as a fact you can confirm in DevTools in under a minute.

Privacy you have to trust is a promise. Privacy you can verify is an architecture. We picked the one you can check.