Most people picture an upload as one hop. It is closer to seven, and every stop on the way is a place where somebody's policy has to hold rather than somebody's code. The services described here are competent, and there is no clever architecture that avoids any of this — which is the point.
The route
Your browser opens a TLS connection and sends the bytes. That much most people know, and it is the part that is genuinely well solved: in transit, the file is unreadable to anyone watching the wire.
The interesting thing happens at the other end. TLS terminates at the edge — a load balancer, a CDN node, a reverse proxy — and from that point the file is plaintext again. It has to be. Something is going to read it.
Four of those stops hold the contents rather than passing them along. The edge, because it has to reassemble the upload before forwarding it. Temporary storage, because a web request cannot hold a 40 MB PDF open while a worker gets around to it. The worker itself, which reads the file, writes an output, and usually leaves both on its own disk until something cleans up. And result storage, which keeps the finished file until you click download — and for a while after, because you might click twice.
Why it is built this way
Every one of those stages exists for a reason that has nothing to do with your data. You cannot process a large file inside the request that uploaded it, because the request would time out and one slow document would block a whole server. So the upload is accepted, parked, and picked up separately. That is a queue. Queues need somewhere to park things, so there is storage. Workers scale independently of the front end, so they need to fetch what they are working on rather than receive it.
It is the correct design for the problem, and a service that did it differently would be worse at its job. The copies are a consequence of the shape rather than a shortcut anyone took.
What a deletion promise is
Read the security page of any large PDF service and you will find a sentence like files are permanently deleted one hour after processing. That is a real commitment and the good ones keep it. Some publish audits. Some are ISO 27001 certified, which means an assessor has looked at how they handle data and found the process sound.
What it says is: we have built a thing that holds your file, we will remove it, and here is our record of doing what we say. Trusting that is not naive. It is how almost all software works, and refusing to ever trust an operator would leave you unable to use a bank.
But it is a promise about behaviour, and behaviour has to be verified by someone. You cannot check it yourself. Nothing you can observe from your side distinguishes a service that deletes in an hour from one that meant to and has a broken cron job.
The risks that exist only because a copy does
None of these require anyone to act in bad faith, which is the point of listing them:
- A breach reaches what exists. An attacker who gets into result storage gets whatever is sitting in it at that moment. A service holding files for an hour has an hour's worth of documents to lose; one holding them for thirty days has thirty days'.
- A legal request reaches what exists. A subpoena or a preservation order can compel a company to hand over, or stop deleting, what it holds. This is lawful and ordinary and has nothing to do with the company's intentions.
- Backups outlive policies. The deletion job runs against live storage. Snapshots taken before it ran can sit in a different system on a different schedule, and reconciling the two is a job somebody has to have remembered to do.
- Logs remember more than you would think. Contents are rarely logged. Filenames very often are, and
2026-q3-redundancies-final.xlsxtells a story without anyone opening it. - Configuration is one checkbox deep. The recurring news story about a publicly readable storage bucket is never about a company that wanted one.
The common thread is that each risk is proportional to what is being held, for how long, in how many places. Reduce the copies and you reduce all of them at once, without trusting anybody more or less.
The other way round
A browser can do most of this work. It can read a file you choose, parse it, rewrite it and hand you the result, without a single byte going anywhere — not because the site promises restraint but because there is no endpoint to send it to. The file never enters the diagram above. There is no route.
That is what every tool on this site does, and it has limits worth being straight about. OCR will run in a browser and does not need a server — but it reads a difficult scan far less accurately than a cloud service, and Arabic worse than that. PDF to Word means inferring a structure the file never recorded, and the good implementations are large. When you need one of those, the right answer is a service that does it properly, and its retention policy is the thing to read.
How to tell which kind you are using
Two checks, and neither takes a minute.
Watch the network. Open your browser's developer tools, switch to the Network tab, and use the tool. If your file is being uploaded you will see it: a request the size of your document. If nothing of that size leaves, nothing of that size left.
Turn off the internet. Load the page, disconnect, then use it. Work that happens on your machine keeps happening. Work that happens on a server stops immediately, and no amount of marketing survives that test.
The second one is the one to remember. It takes fifteen seconds, it needs no technical knowledge, and it cannot be faked in either direction.