The hidden risks of online file converters (and how local processing fixes them)

Type "PDF to Word" into a search engine and you will get pages of free converters, each promising to do the job in seconds. Almost all of them work the same way: you choose a file, it travels across the internet to their server, the server runs the conversion, and a download link comes back. The whole interaction feels like the file just changed shape on its own.

It did not. It was uploaded to someone else's computer, processed in their environment, written to their disk, often logged, sometimes scanned, and - depending on the operator - sometimes retained for far longer than they admit. For a photo of your dog this might not matter. For a tax return, a passport scan, a contract, an unpublished manuscript, a medical record, an internal company spreadsheet, or anything you would not email to a stranger, it matters a lot.

This piece is about what actually happens when you use a typical free online converter, why the risk is structural rather than a matter of trusting any one operator, what the documented incidents look like, and how the same conversions can run entirely on your device with modern browsers.

What "free online converter" really means

A converter site has the same costs as any other web service: servers, storage, bandwidth, an engineering team, customer support. Conversion in particular is compute-heavy. Rendering a 200-page PDF to Word, transcoding a 30-minute video, running OCR over a stack of scans - these are the kinds of operations cloud providers charge real money for. None of it is free for the operator.

So how is it free for you? In practice there are five business models, often layered:

1. Ads. Display ads, pop-unders, redirected downloads. Common and relatively benign.
2. Upsells and paywalls. Free for small files, paid for large ones. The free tier is a funnel.
3. Lead capture. An email or account is required to download the result. Your address gets reused or sold.
4. Data extraction. The contents of files - text, metadata, aggregated patterns - are mined. Sometimes disclosed in the privacy policy using language like "we may use uploaded content to improve our services."
5. Outright malicious. A small number of sites exist to harvest documents, distribute malware via the "converted" download, or both. These come and go quickly and are hard to spot from the landing page.

You cannot reliably tell which model a given site uses by looking at it. The best-designed converters and the most extractive ones look identical.

The structural problem

Even setting aside bad actors, the server-upload model has a few problems that no amount of operator goodwill can fully solve:

• You lose physical control of the file. Once it is uploaded, you are trusting someone else's policies, retention practices, backup schedules, log rotation, employee access controls, subprocessors, and the security of every layer between their load balancer and their disk.
• "We delete after one hour" is unverifiable. It is a promise, not a property of the system. Backups, replicas, error logs, debugging captures and CDN caches routinely outlive the stated retention window. The operator may not even know everywhere the file went.
• Privacy policies are written to be flexible. Phrases like "to provide and improve the service," "service providers and partners," and "as required by law" are doing a lot of work. They are also not promises - they can be changed.
• Breach exposure. Every uploaded file becomes part of an attractive target. Converter operators are not generally regulated like banks or hospitals, and many run on small teams without dedicated security.
• Legal jurisdiction. The site looks like a neutral utility but is incorporated in a specific country, hosted in another, and subject to the subpoena and lawful-access regimes of both. Your file follows those rules, not yours.
• Subprocessor sprawl. Many converters do not do their own conversion. They forward your file to a third-party API. That API might forward to another. Each hop is a copy.

This is why "is this converter trustworthy?" is the wrong question. The right question is "does this workflow require me to trust anyone in the first place?"

What the public record actually shows

The risks above are not hypothetical. A few patterns are well documented:

• Indexed uploads. Researchers and journalists have repeatedly found that converter and "anonymous file share" sites leave uploaded files accessible to anyone who can guess or scrape the URL pattern. Search engines have indexed entire corpora of supposedly private documents that were never meant to be public.
• Malware-laced downloads. The FBI's Denver field office issued a public warning in 2025 about free online file-conversion sites that bundled malware into the converted file. The advisory specifically called out PDF converters, MP3 converters, and file-merge sites. The technique works because users execute the result without thinking - it is supposed to be their own file coming back.
• Credential and token theft via "converted" documents. Macro- enabled Office documents and rigged PDFs returned by sketchy converters have been used to deliver infostealers. Once a session token from a logged-in browser is exfiltrated, single-sign-on across email, cloud storage, and internal company tools is compromised.
• Privacy-policy expansions. Several converter and "AI document" services have, over time, broadened their privacy policies to allow training on uploaded content, with no notice to existing users.
• Acquisitions and shutdowns. Converter sites change ownership regularly. The new owner inherits whatever data the old one stored, under whatever new policy they choose to write. "We will delete on request" is worth what the new operator decides it is worth.

None of this requires the operator to be malicious. Most are not. The point is that the model itself - upload your file to a stranger's server - has a wide attack surface that grows over time.

The compounding factor: what is in your files

People underestimate how much sensitive material runs through "boring" file conversions:

• A scanned passport or driver's license being converted from PDF to JPEG.
• A signed contract being merged with an addendum.
• A bank statement being converted to text for a budgeting app.
• A medical record being compressed before emailing a specialist.
• A CV with a home address and phone number being converted from DOCX to PDF.
• A real-estate floor plan with a client's name in the title block.
• Photos of an apartment for a marketplace listing, complete with GPS coordinates in the EXIF data.
• A spreadsheet of customer emails being saved as CSV before importing somewhere.
• A draft of an unannounced product, an unreleased song, an unpublished manuscript.

Any of these going through a free server-side converter is a small but real privacy event. Doing it dozens of times across your career, across your family, across a small business, adds up.

Why local processing fixes this

The fix is structural, not procedural. Instead of sending the file somewhere to be processed, do the processing in the same place the file already lives - your device. Three things made this practical in the browser specifically:

1. WebAssembly lets battle-tested native libraries run inside the browser tab at near-native speed. The same FFmpeg that powers most of the world's video processing, the same libheif that decodes iPhone photos, the same image and PDF libraries used in desktop software - all compile to wasm and run in the page.
2. The File API and Blob let JavaScript read the bytes of a local file directly into memory without uploading. The browser hands them to the script; the script never has to call the network.
3. Modern device performance. A mid-range laptop or recent phone has more raw compute than the shared cloud instance behind most free converter sites. There is no performance reason to outsource the work.

Once the conversion runs locally, every category of risk above either shrinks dramatically or disappears:

• No upload means no breach exposure on the operator's side, no log entry, no retention question, no subprocessor chain, no jurisdictional ambiguity. There is nothing to leak because nothing left.
• "Trust me" becomes "verify me." Open the network panel in your browser's developer tools, run the conversion, and watch what happens. A site that processes locally has no upload request to your file's bytes. A site that ships your file to a server cannot hide it - the request is right there.
• Privacy policy becomes mostly redundant for the file content itself. There is no document to be careful about because the operator never touched it.
• Works offline, which is also a security property. The tool cannot phone home with what it does not have a connection for.

How to tell whether a converter is actually local

Marketing language is not enough. "Privacy first," "secure," "we respect your data" appears on plenty of sites that upload everything. A few concrete checks:

1. Open the network panel (Chrome and Edge: F12 then Network; Firefox: F12 then Network; Safari: enable the Develop menu, then Web Inspector). Filter by your file size or by request type "Fetch/XHR." Run the conversion. If your file's bytes get POSTed to the server, it is not local. If only small JSON or analytics calls fly, it is.
2. Try it offline. Load the page, then disable your network (airplane mode or DevTools "Offline"). If the conversion still works, the processing is in the browser.
3. Check the size of the page. Local converters tend to ship large WebAssembly bundles - tens of megabytes is common for a video tool. A tiny page that converts large files quickly is almost certainly server-side.
4. Read the privacy page for specifics. Look for concrete claims like "we do not have an upload endpoint," "all processing runs in your browser," "you can verify this in your network panel." Vague reassurances do not count.

When a server-side converter is genuinely the right call

Local-first is the right default, but it is not always the right answer. A few cases where a server makes sense:

• Very large files on very weak devices. A 10 GB video on a five-year-old phone will struggle in any browser. A workstation will not.
• Format conversions that depend on huge proprietary engines - for example, high-fidelity DOCX to PDF that needs Microsoft's own renderer.
• Workflows you control end to end, like running your own converter in your own infrastructure for your own organisation.

For everything else - photo format swaps, audio clips, ordinary PDFs, compressing images for email, stripping metadata, merging documents, or turning a stack of photos into a PDF - local processing in a browser tab is faster, more private, and more honest about what it is doing.

The Privvert position

Privvert was built around exactly this argument. Every conversion in our toolkit runs in the browser, on your device, using the same JavaScript and WebAssembly engines that ship with your browser. There is no upload endpoint for file contents. There is no "we keep your file for one hour" policy because there is no file on our side to keep.

You can verify it the same way you would verify any other site: open the network panel, run a conversion, watch the requests. The pattern is the page loading once, then nothing as your files are processed. That is the property we wanted, and it is the property the model gives you. Browse the toolkit or jump straight to the universal converter if you want to see it in action.

The wider point is bigger than any one tool. Free server-side converters were a useful hack in 2008. In 2026, on a modern phone or laptop, sending your files to a stranger to be reshaped is not a convenience - it is a tax on your privacy that you do not have to pay.

Frequently asked questions