When you upload a file to a server based converter, it is copied over the network to a machine you do not own, written to a temporary directory, processed by software running on that server, and offered back to you as a download. From the first byte onward, the file is in someone else's hands.
The pipeline is unremarkable and fairly consistent across services. Your browser sends a POST request with the file encoded as multipart/form-data; the server saves it under a randomised name in a temporary folder; a worker process hands it to a command line tool such as Ghostscript, FFmpeg or ImageMagick; the finished output is stored and a link is returned; a scheduled job deletes old files. Every step after the upload happens on hardware you have no visibility into, and the deletion step is a policy the provider controls rather than a guarantee the technology enforces.
The question people actually ask is not how a converter works, it is whether the file is gone afterwards. That question has two parts: the mechanics of an upload are public and easy to observe, while what a specific company does with its storage afterwards is not.
Image Compressor
The opposite architecture. The file is read into the browser tab, resized on your own CPU and handed back as a download. Nothing is transmitted.
The pipeline behind an upload button
Nearly every server based converter follows the same six stages, and each stage is a place where a copy can exist.
| Stage | What happens |
|---|---|
| 1. Upload | The browser sends the file as a multipart/form-data POST request over HTTPS. |
| 2. Landing | The server writes the file to a temporary directory, often on the same disk that serves other users. |
| 3. Queue | A job is created and a worker picks it up, sometimes seconds later, sometimes not until the queue drains. |
| 4. Conversion | A command line engine such as Ghostscript, FFmpeg, ImageMagick, qpdf or LibreOffice does the work. |
| 5. Delivery | The output is stored and a link or a streaming response is returned to your browser. |
| 6. Cleanup | A scheduled job removes the input and output files when the retention window expires. |
HTTPS protects stage one and stage five. It stops a network observer from reading the file in transit, and it does nothing at stages two, three, four and six, because there the file sits in readable form on a machine that belongs to someone else.
What a deletion promise actually is
When a site says files are deleted after one hour, it is describing an intended state of its storage, not a technical property of the upload. The distinction matters more than it sounds.
A local tool that never transmits the file has a structural guarantee: there is no remote copy to delete, so there is nothing to get wrong. A server based tool has a procedural promise: a job will run, the job will find the file, and the deletion will succeed. That promise can fail in ordinary ways. A crashed worker can leave a file behind with no record to clean up. A failed conversion can park the file in an error queue the cleanup job does not scan. A cache layer in front of the download endpoint can hold a copy longer than the origin, and backups can capture a snapshot at the wrong moment. None of these require anyone to be dishonest, and none are visible to you.
There is also a scope problem. Retention statements usually describe the uploaded file and the converted output, and rarely enumerate derivatives: preview thumbnails, extracted text for search, virus scan results, logs with original filenames, or analytics events that record a file hash. A short window on the headline object does not cover all of them.
How to read a retention policy
You do not need legal training to read a privacy page usefully. Separate sentences that describe a mechanism from sentences that describe an intention.
- Mechanistic wording. Files are stored in an encrypted bucket and destroyed automatically after 60 minutes by a scheduled job. This tells you where the file lives, for how long, and what removes it.
- Intentional wording. We respect your privacy and take data protection seriously. This is true of nearly every provider and tells you nothing you can act on.
- Permission wording. We may retain files to improve our services, to comply with legal obligations, or to share with trusted partners. This is the sentence that decides the risk, and it is usually in the section people skip.
- Absent wording. No retention section, no data processing detail, no contact for privacy requests. Treat silence as the least protective option available.
Two phrases are worth hunting for. The words may retain mark a discretionary decision rather than a fixed period, and the names of subprocessors matter too, because a file forwarded to a third party for scanning or storage is subject to that party's policy as well.
What local processing removes from the picture
A browser based tool runs the same kind of engine, FFmpeg or Tesseract or a canvas pipeline, but compiled to WebAssembly and executed inside your tab. That is how Compress PDF and PDF to Text work, and the architecture changes which stages exist at all.
| Browser based tool | Server based converter | |
|---|---|---|
| Copies that leave your device | None | At least one, usually two |
| Retention | Not applicable | Governed by their policy |
| Can be audited by you | Yes, in the network panel | No |
| Survives a provider breach | Yes, there is nothing to breach | Depends on what was stored |
| Speed | Limited by your device | Limited by their queue |
| Large files | Bounded by browser memory | Bounded by their plan limits |
That last pair of rows is the honest trade. A server with dedicated hardware finishes a heavy job faster than a laptop and accepts files a browser cannot hold in memory. For a 200 MB video you found online and need as MP3, uploading is a reasonable engineering decision. For a scan of a signed agreement, it is much harder to justify.
When uploading is a reasonable choice
Uploading is not a mistake in itself, and treating every server as hostile is its own kind of failure, because it pushes people towards worse workarounds. The question is what is in the file and who is affected if it is read.
| File | Uploading it |
|---|---|
| A stock photo or a screenshot of a public page | Fine. There is nothing in it that is not already public. |
| A published brochure, menu or price list | Fine. It is a marketing asset you already distribute. |
| Your own personal photo of a landscape | Low risk, though the file carries location metadata. |
| A PDF that is already circulating publicly | Low risk, provided the copy you have is not annotated. |
Note the qualifier in that last row. A file being public does not mean the version in your hands is public. Comments, tracked changes and revision marks travel with the file, and those frequently contain thinking that was never meant to be shared. Stripping a document is a separate job from converting it.
When it is not
These categories should not go to a general purpose converter, no matter how good its privacy page looks.
- Identity documents. Passports, driving licences, national ID cards, residence permits. A scan is enough to attempt identity fraud, and the file cannot be un-leaked.
- Contracts and legal filings. Anything unsigned, unredacted or under negotiation, including the annotated drafts that circulate inside a deal.
- Medical records. Test results, referral letters, insurance claims, disability documentation. These identify a person and describe their health at the same time.
- Employee and candidate data. Offer letters, performance reviews, disciplinary notes, payroll files, background check output. The organisation holds duties towards these people that a converter site has never agreed to.
- Customer data. Contact lists, invoices, support attachments, anything that pairs a name with a purchase or a complaint.
- Unreleased material. Product designs, unreleased screenshots, financial statements before publication, source documents behind a launch.
If a file in that list genuinely needs converting, convert it locally, or convert a redacted version. The same work can usually be done without the file leaving the machine it is on.
How to check a specific site yourself
The general explanation above matters less than what a particular site does, and you can find that out in about two minutes without trusting anyone's word for it.
- Watch the network panel. Add a small test file and look for a POST request. If a request body carries your file, the file went to a server, whatever the marketing page says.
- Disconnect and retry. Turn off your network and repeat the operation. A local tool still works; a server tool fails or hangs.
- Read the privacy page for the retention section. Note whether it gives a duration and a mechanism, or only an intention.
- Check what the tool sends after the job. Analytics, error reporting and font requests are normal. A request that carries the file contents a second time is not.
There is a longer walk through of those checks, including what each result means and the cases where the answer is genuinely ambiguous, in how to tell whether a website uploads your files.
Where this explanation stops
This page describes how the common architecture works and how to reason about it. It cannot tell you what any named company actually does with a file, and nothing on a public page substitutes for inspecting a tool yourself or for the position your own organisation has taken on third party processing.
Three limits are worth stating plainly. A local tool is not automatically risk free: a browser extension with broad permissions, a compromised dependency or a shared computer can expose a file that never left the device. An upload can also be acceptable and still be the wrong choice, for example when it sends a document into a workflow with no audit trail. And this article makes no claim about any jurisdiction's legal requirements, so decisions that carry real consequences belong with your own legal and security teams.