When you upload a file to a website, where does it actually end up?

You drag a PDF onto a website to compress it. A progress bar appears, a few seconds pass, and you download the smaller file. The whole thing looks like it happened right there in front of you.

Usually it didn’t. Your PDF travelled across the internet to a computer you have never seen, in a country you didn’t pick, owned by a company whose name you probably couldn’t recall. It was processed there, and sent back from there.

That progress bar you watched wasn’t the work. It was the upload.

What that copy actually means

Let’s say this without melodrama: most of these services have no interest in your files. They process millions a month and delete them because storage costs money.

The problem isn’t bad intent. It’s that a copy existed, and while it exists it is subject to things you don’t control:

• The provider’s staff. Anyone with filesystem access can read them. An internal policy forbidding it is not the same as it being impossible.
• Backups. A file “deleted” after 30 minutes may sit in a nightly backup for months. The deletion these policies describe is almost always deletion from the live system.
• Breaches. If the provider is compromised, whatever was stored at that moment is affected. There is no way to know in advance whether your file was inside the window.
• Legal requests. A server is subject to the law where it sits. If that jurisdiction isn’t yours, your data is governed by rules you never agreed to.
• Subcontracting chains. Many services don’t own servers: they rent infrastructure from a third party, which uses a data centre run by a fourth. Every link adds people with possible technical access.

None of this requires anyone to act in bad faith. These are structural consequences of the file leaving your computer.

What the fine print usually says

Privacy policies for conversion services reuse a handful of phrases. It’s worth learning to read them.

“We automatically delete your files after one hour.” This almost always means the file is removed from the working disk. It says nothing about backups, server logs, or the intermediate copies the conversion itself produced.

“We do not access the contents of your files.” That’s a statement of policy, not of architecture. It describes what the company promises to do, not what it is technically able to do. If the file sits unencrypted on their disk, access is possible by definition.

“We use SSL encryption.” True, and good — but it protects the file in transit, not once it arrives. It’s like praising the armoured van’s locks without mentioning what happens in the warehouse.

“We may use data to improve our services.” Written broadly, this clause covers a lot of ground. It deserves a careful read.

None of this is necessarily deceptive. But it was written by lawyers to protect the company, not to inform you.

When it genuinely matters

For a holiday photo, honestly, it doesn’t.

The calculation changes with certain files:

• Contracts, payslips, financial paperwork
• Medical reports and test results
• Scanned identity documents
• Work material covered by a confidentiality agreement
• CVs, which bundle your name, phone, address and work history into one file
• Family photos, especially of children

And there’s a consideration people forget: if you work for a company, uploading corporate documents to an outside service may breach your own employer’s policy, no matter how secure that service is. Many confidentiality agreements explicitly prohibit transferring material to unapproved third parties.

The technical alternative

For a long time, uploading was the only option. JavaScript couldn’t decode video or re-encode an image at any reasonable speed, so the heavy lifting had to happen on a server.

That changed with WebAssembly, a format that lets the browser run code compiled from languages like C or Rust at close to native speed. Programs that had existed for decades — FFmpeg for video, image libraries, PDF engines — were compiled to WebAssembly and now run inside a tab.

The consequence is direct: the file no longer needs to go anywhere. It opens in browser memory, gets processed by the same code a desktop program would use, and the result lands in your downloads folder. The network is never involved.

This isn’t a privacy-policy promise. It’s a property of how the tool is built. The difference between those two things is enormous: one asks you to trust it, the other doesn’t need to ask.

How to check for yourself

You don’t have to take any website’s word for it, including this one. You can verify it in thirty seconds:

1. Open developer tools with F12
2. Go to the Network tab
3. Use the tool on any file
4. Look at the request list

If processing is local you’ll see requests for scripts, styles and maybe analytics, but nothing uploading megabytes. Sort by size: a real upload is impossible to hide there.

There’s an even blunter test. Load the page, disconnect from the internet, and use the tool. If it works offline, it is mathematically impossible for it to be sending anything anywhere.

That test isn’t up for debate, and no privacy policy comes close to it.

What local processing can’t do

It would be dishonest to sell this as a universal answer. The limits are real:

• It depends on your machine. An eight-year-old laptop will be slower than a server with thirty-two cores. On large files you’ll notice.
• It uses your RAM. A multi-gigabyte video may simply not fit. A server doesn’t have that problem.
• The first load is heavy. The WebAssembly engine can be tens of megabytes, downloaded once.
• Some things it just can’t do. Large AI models, work needing a dedicated GPU, or jobs that run for hours still require a server.

For everyday tasks — converting, compressing, trimming, extracting — local processing covers almost everything. For the rest you still need a server, and there the right question isn’t how to avoid it, but who you trust with the file.

The short version

Uploading a file to an online service rarely ends badly. But “rarely ends badly” is a statistical claim, and you don’t upload files on average: you upload yours, specifically.

When a tool exists that does the same job without the file leaving your computer, choosing it isn’t paranoia. It’s just removing a risk you no longer need to take.