Is it safe to upload files to free online converters?

The honest answer is "sometimes, and the sites that are risky look exactly like the sites that are careful". There is no badge, no shared standard and no independent audit behind the words "your files are deleted after one hour". Two converters can display the same promise while one runs a single server in a rented rack and the other pipes every upload through three unnamed subcontractors.

This is not an argument that uploading a file is always dangerous. It is an argument for knowing what you are agreeing to, so the decision is deliberate rather than habitual.

What happens to a file after you press upload

1. It travels encrypted. HTTPS protects the file in transit. This part is reliable, and it is not where the risk lives.
2. It is written to disk somewhere. Every service stores it at least briefly, because the conversion runs on a server process reading from a filesystem. That copy may be on the application server, in a shared object store, or in a queue waiting for a worker.
3. It is processed, and often duplicated. A conversion creates an output file, sometimes intermediate files, and a retried job can leave an orphaned copy behind.
4. It is deleted, or it is not. This is the step you cannot verify. Retention is a policy, not a technical guarantee, and policies change without notice.
5. It may exist in backups. A file deleted from the live system can persist in a nightly backup for weeks. Most retention promises describe the live system only.

The specific risks, ranked by how often they bite

• Accidental publication. The most common failure is not a breach. It is a converted file left at a guessable or indexed URL, or a gallery of recent conversions that anyone can browse. If the output address is short and predictable, treat the file as public.
• Retention you did not read. "Deleted after one hour" and "deleted when you close the tab" are different promises, and neither tells you whether the file survives in a backup archive. Look for a stated period and a stated deletion mechanism.
• Subprocessors. A small converter often runs on a large cloud provider and may use a third party for tasks such as virus scanning or format detection. The policy should name those categories. A policy that mentions "trusted partners" without naming them tells you nothing.
• Terms that grant rights over your content. Some terms of service include a licence to store, reproduce and create derivative works from uploaded content. That wording usually exists to make the service function legally, but it is written broadly. Read the licence clause, not only the retention clause.
• Legal compulsion and account linkage. A file held by a third party can be requested by a court or an authority, and if you were signed in, the upload is tied to your identity.
• Breach exposure. A server holding a queue of uploaded documents is a valuable target, and the provider's security posture is invisible from the outside.

How to read a privacy policy for the details that matter

Policies are long, but four questions cut through most of the length:

1. How long are files kept, in time units? A specific period such as four hours is meaningful. "As long as necessary" is not.
2. Is the file used for anything besides the conversion? Training machine learning models, improving the service and analytics are three different answers, and training on customer content is the one to look for explicitly.
3. Who else receives it? Look for a subprocessor list or named provider categories, and for any transfer of data between jurisdictions.
4. What happens to the output? Some services delete the input promptly and keep the result at a link indefinitely, which is still a copy of your document on a stranger's disk.

One practical test is whether the site needs an account. A converter that works without one, with no cookies beyond the essential and no client-side analytics suite, has less to leak and less to hand over.

When uploading is genuinely fine

Not every file deserves this much thought. Uploading is a reasonable trade when the file is already public, when it contains nothing that could identify a person or an organisation, or when the conversion is not available anywhere else and the content is trivial. Converting a public domain map or checking a synthetic image is not a meaningful risk.

The categories that should never go to an unknown server are short and recognisable: identity documents, passports and driving licences; medical records and insurance correspondence; contracts, NDAs and anything marked confidential; payslips, bank statements and tax returns; property documents; source code under a client agreement; and any file covered by a data protection obligation you hold on someone else's behalf. In several jurisdictions, sending personal data to a service with no data processing agreement is a compliance problem in its own right.

The alternative that removes the question

Most of what these sites do can now be done inside the browser. Merging and splitting PDFs, compressing and resizing images, removing backgrounds, running optical character recognition, creating and extracting archives and formatting JSON are all achievable with JavaScript and WebAssembly on the machine that already holds the file. When a tool works that way there is no upload stage to reason about, no retention window to trust and no policy to read. You can confirm it yourself: open your browser's developer tools, switch to the Network tab, and watch while you run the job. If the only requests are for the page and its scripts, nothing left the machine.

The trade-off is worth stating. In-browser tools are bound by your device's memory and processor, so a very large job may be slower or may not fit at all, and some narrow conversions genuinely need a server. Where that is true, check whether a local tool can do it, then whether you can redact or reduce the file first, and only then decide whether the upload is worth it.