Skip to content

Privacy & security

What actually happens to your file when you upload it

Not a scare story — a plain account of where a document goes after you drag it into a website, how many copies that makes, and what "deleted after an hour" covers.

QuickFileToolkit Team6 min read

Drag a PDF onto a website, watch a progress bar, download the result. It feels like one action happening in one place. It is not — and it is worth knowing what it actually is, because the answer decides which documents you should be comfortable putting through it.

This is not an accusation. The great majority of these services are run by real companies doing exactly what they advertise. But “we delete your files” is a statement about one specific copy, and there are usually several.

The short version

  • Uploading a file hands a copy to infrastructure you cannot inspect, and that copy is decrypted the moment it arrives.
  • A single upload typically becomes four to six copies across different systems before you download the result.
  • HTTPS protects the journey, not the destination.
  • “Deleted after an hour” almost always means the working copy — not backups, not replicas, not logs.
  • None of this is unusual or sinister. It is just how server-side software works, and it is the reason the alternative exists.

The journey, stop by stop

Your browser reads the file and opens a connection. So far nothing has left your machine.

The network. The file travels over HTTPS, so your internet provider, the café Wi-Fi and anyone in between see an encrypted stream to a domain and nothing more. This part genuinely is safe, and it is the part people worry about most.

The entry point. A load balancer or reverse proxy terminates the encryption. From here on, inside that provider’s network, your document is plain data. This is the moment the lock comes off, and it is invisible from your side.

Storage. The file is written somewhere durable — usually an object storage bucket — so it survives long enough to be processed. It may be encrypted at rest, which protects against someone walking out with a disk. It does not protect against anything with legitimate access to the bucket.

The worker. A separate process picks the file up and does the actual job. It may run on a different machine and may write intermediate files of its own — extracted images, rendered pages, a temporary output. Those temporary files are also copies.

The result. The output is written back to storage and you are given a link. Frequently that link is served through a CDN for speed, which means it may be cached at edge locations around the world, on a schedule the application does not control.

Logs. Every stage above logs. Filenames, sizes, timestamps, your IP address, your browser. Logs are usually kept far longer than files — thirty to ninety days is ordinary — and they are shipped to yet another system for searching.

That is a normal, competently built pipeline. Count the copies: storage, worker temp files, output, CDN edges, backups, logs. Six systems, from one drag and drop.

What “deleted after one hour” covers

It is a real promise, and reputable services keep it. It is also narrower than almost everyone reads it as. Typically it means the working copy in the primary bucket. What it usually does not describe:

  • Backups and snapshots taken while your file was present. These exist so the service can recover from failure, and they are not selectively editable — removing one file from a snapshot is not a thing you can do.
  • Cross-region replicas, if storage is replicated for durability.
  • CDN caches of the download URL, which expire on their own schedule.
  • Logs, which are the whole point of logs.
  • Anything a subprocessor holds, if the heavy lifting runs on a third-party service.

Again — this is ordinary. But “deleted after an hour” and “gone” are different statements, and the gap between them is where people’s expectations sit.

Where the risk actually is

Not, generally, the company reading your documents. There is no business model in it and enormous liability if caught. The realistic risks are duller:

Breaches. A service holding millions of documents is a target, and a misconfigured storage bucket is one of the most common serious mistakes in the industry. Your file does not need to be interesting for it to be included.

Insiders. Engineers and support staff can generally access production storage; that is how outages get fixed. Good companies control and audit it. Access still exists.

Acquisitions and closures. The privacy policy you agreed to belongs to the company that wrote it. Companies get bought, and data is an asset that transfers.

Legal process. Data that exists can be compelled. Data that was never collected cannot be.

The free ones. If a service is free, ad-free, and has no obvious revenue, it is worth asking what pays for the servers. Sometimes the answer is fine. Sometimes the answer is the analytics.

What actually changes the picture

A tool that runs in your browser does the work with code your device has already downloaded. Browsers can read files, decode images, render PDF pages and encode the results without help. When that is how a tool is built, the file is never a network request — there is no bucket, no worker, no CDN copy and no log line, because there was never an upload.

That is how the tools on this site work, and it is not a marketing position so much as a structural one: we cannot leak your documents because we never receive them. Close the tab and the working copy is gone with it, because it only ever lived in your browser’s memory.

The trade-offs are real and worth stating. Local processing is limited by your device, so a very large file on an old phone will be slower than a server would be, and can run out of memory. There is no processing queue you can walk away from. And you have to take the claim seriously enough to check it — which brings us to the useful part.

How to decide, per document

Rather than a rule, a question: if this file appeared in a public database of leaked documents next year, what would that cost me?

  • A holiday photo, a meme, a public brochure. Nothing. Upload it anywhere.
  • A CV, a utility bill, a bank statement. These carry your full name, address and account details — the raw material for impersonation. Worth keeping local.
  • Passports, ID cards, visas, birth certificates. These are the documents identity fraud is built on, and they cannot be reissued easily. Never upload these to a service you have not deliberately chosen to trust.
  • Signed contracts, medical records, anything covered by a duty of confidentiality. Here it may not even be your decision — sending a client’s data through a third-party processor can be a contractual or regulatory problem regardless of how careful that third party is.
  • Anything containing a password, key or one-time code. Treat as compromised if it goes anywhere.

The point

The question is not “are these sites trustworthy”. Most of them are. The question is whether a particular document is worth creating six copies of on machines you will never see, in exchange for a task your own device can usually do in a couple of seconds.

For a lot of files, the answer is a cheerful yes. For your passport scan, it probably is not — and the good news is that you increasingly do not have to choose.

Next: how to check whether a web tool really processes files locally, including a test you can run on this site in about thirty seconds.

Frequently asked questions

Are online PDF tools unsafe?

Most are run by legitimate companies doing exactly what they say. The point is not that they are dishonest — it is that uploading creates copies on infrastructure you cannot see, and the sensitivity of the document decides whether that matters. A holiday photo and a signed contract are not the same decision.

What does "files are deleted after one hour" actually cover?

Normally the working copy in the storage bucket. It usually does not describe backups taken while the file was there, replicas in other regions, CDN caches of the download link, or server logs holding the filename and your IP address. None of that is deceptive — it is just a narrower promise than most people read it as.

Does HTTPS mean my upload is private?

HTTPS protects the file in transit, so nobody between you and the server can read it. It does nothing at all once the file arrives — at that point it is decrypted and sitting on someone else's machine. It is a lock on the road, not on the building.

How can a tool work without uploading anything?

Modern browsers can read files, decode images, render PDF pages and re-encode the result on their own. A site that does this sends you the code and the code does the work on your device, so the file never becomes a network request. You can verify it yourself — the next guide explains how.

I already uploaded a sensitive document. What should I do?

If the service has a delete button, use it — that removes the working copy, which is the copy most likely to be exposed. Then treat the document as having been handled by a third party: if it contained a password or a one-time code, change it. If it was an ID, be aware it existed outside your control for a period, and keep an eye out for anything that suggests it was used.