Your "Free" PDF Converter Is Uploading Your Private Files. Here's Why That's Finally a Choice.

Saroj GT — Sun, 25 Oct 2026 09:26:53 +0000

Last month I opened Chrome DevTools while a popular online "PDF to Word" tool was converting a signed loan agreement for me.

The Network tab lit up with a POST request the exact size of my document.

My file — my full legal name, address, signature — had just been uploaded to a server I'd never heard of before being converted.

The site advertised itself as "free, fast and secure." All three were technically true.
The word private appeared nowhere on the page.

This isn't a scandal. It's how the entire free online file-converter industry has worked since roughly 2010.

Here's the part most devs don't realise: as of 2024, that upload step was already unnecessary. As of 2026, it's a design choice.

Let me show you why — with the actual browser APIs that make it true, and a 20-second DevTools test anyone can run against any converter.

The 20-second test

Open the Network tab in DevTools. Hit Record. Drop a file into the converter.

POST  /api/convert       Request Payload: 4.7 MB   ← your file, going somewhere

If you see that, your file is going to a server. No amount of HTTPS, no privacy policy, no "deleted within an hour" badge changes that.

A truly in-browser converter looks like this instead:

No new requests fired.

That's it. If the Network tab is silent during the conversion, the work happened on your device.

Try it against any converter you've used before. The results are depressing.

Why every "free" converter uploads: it's commercial, not technical

Here are the current free-tier limits of the big four:

Service	Free limit	Enforcement mechanism
Smallpdf	2 tasks/hour, 15 MB file cap	Server-side rate limit
iLovePDF	25 MB file cap, batch requires signup	Server-side rate limit
CloudConvert	25 conversions/day	API key metering
Zamzar	2 files/day, 50 MB cap	Account metering

None of these are technical limits. A modern laptop can transcode a 500 MB video in a browser tab. They exist because the server pays per CPU-second and that cost has to be recouped. Rate-limiting the free tier is the recoup mechanism.

The upload step is what enables the rate-limiting. If you did the work on your own device, there would be nothing to meter.

┌─────────────────┐    upload     ┌──────────────┐
│   your browser  │ ────────────▶ │ their server │ ─── metered CPU-time ──▶ $$$
└─────────────────┘               └──────────────┘

                        vs

┌─────────────────┐
│   your browser  │ ─── free CPU on your laptop ──▶  🤷
└─────────────────┘

Privacy and the metering model are at direct odds.

What the browser can actually do in 2026

Three capabilities, in combination, killed the need for server-side file conversion for ~90% of operations:

1. WebAssembly (stable 2019)

C/C++ libraries now run inside a browser tab at near-native speed. Entire format ecosystems:

// pdf-lib — PDF manipulation
import { PDFDocument } from 'pdf-lib';
const doc = await PDFDocument.load(bytes);

// pdfjs-dist — PDF rendering/extraction
import * as pdfjs from 'pdfjs-dist';
const pdf = await pdfjs.getDocument(bytes).promise;

// heic2any — Apple HEIC → JPEG
import heic2any from 'heic2any';
const jpeg = await heic2any({ blob: heicFile, toType: 'image/jpeg' });

// ffmpeg.wasm — audio/video transcoding
import { FFmpeg } from '@ffmpeg/ffmpeg';
const ffmpeg = new FFmpeg();
await ffmpeg.load();
await ffmpeg.exec(['-i', 'input.mp4', '-vn', 'output.mp3']);

All of this runs client-side. No upload. No API key. No daily cap.

2. Big memory per tab

Chrome and Safari now routinely allocate 1–4 GB per tab for sustained workloads. That's enough to hold a 500 MB video in memory while FFmpeg transcodes.

3. The File System Access + Streams APIs

// Read a 2 GB file off disk, decode, re-encode, write back — zero server round-trip
const [handle] = await window.showOpenFilePicker();
const file = await handle.getFile();
const stream = file.stream();
// pipe through decoder → encoder → saveAs()

The browser can now read a 2 GB file off disk, pipe it through a decoder, re-encode it, and write it back — without the file ever leaving the device.

What's actually solved client-side right now

Things that absolutely work in the browser today, no server involvement:

PDF to Word (pdf-lib + pdfjs-dist)
Word to PDF (docx + pdf-lib)
Merging + splitting PDFs (pdf-lib)
PDF to image / image to PDF
HEIC to JPG (heic2any)
Any image-to-image conversion (<canvas> + OffscreenCanvas)
MP4 to MP3 and most audio extraction (ffmpeg.wasm)
Video → GIF
Video transcoding under ~500 MB

Honest exceptions still worth sending to a server:

OCR of scanned documents at scale (though tesseract.js runs locally for small jobs)
Very large video transcoding (>2 GB)
Format families with licensing restrictions (some proprietary CAD formats)

For the 90% most people care about — HEIC off an iPhone, a PDF into a Word doc, a few photos into a PDF — the server version is a legacy operation.

"But files are deleted after an hour"

The one-hour deletion window is the thing privacy policies always lead with. As a guarantee, it's close to meaningless:

Deletion is a promise about the current operator. If the company is acquired, the policy can change retroactively.
Deletion is from active storage. Backups and logs often outlast the deletion window by weeks.
Deletion is from their systems. Anyone who intercepted the TLS stream on the way up — ISP, corporate SSL-inspection appliance, nation-state at a backbone — still has their copy.
Deletion requires good-faith operation. If the company is breached, your file is gone before the one-hour window starts.

A document that never leaves the device cannot be any of these things.

For most everyday files, the trade-off is fine. For a specific category of documents it is not:

Legal documents — contracts, NDAs, settlement letters. Attorney-client privilege may apply.
Medical records — HIPAA requires a signed Business Associate Agreement with any processor. The free online converter has not signed one with you.
Financial documents — bank statements, tax returns. Contain exactly the fields needed for identity fraud.
Government IDs — passports, driver's licenses. Industry best practice: never upload without a signed DPA.
Early-stage startup documents — term sheets, cap tables. Material non-public information.

The irony: the free online converter is exactly the tool non-technical users reach for when handling precisely these kinds of files, because the files are urgent and the tool is one Google search away.

A quick checklist, for sensitive files

Run this against any file converter before you drop a sensitive document into it:

Does it show an "upload" progress bar before converting? → File is going to a server.
Does the privacy policy name the servers' country? → EU providers under GDPR usually do; US ones often don't.
Does it work offline? Open the tool, go offline, reload, drop a file. If the conversion works, it's local. If it hangs, server-based.
DevTools Network tab silent during conversion? → Local. File-sized POST request? → Server.
Is there a named operator with a contact email? → Changes the recourse story if something goes wrong.

The in-browser alternatives

I maintain one of these: FileConverterTools. It's intentionally minimal — around a dozen converters, each one running entirely in-browser via WebAssembly, no account, no file-size cap on the free tier.

It's not the biggest tool catalogue on the web. It's just the one where the answer to "where did my file go" is "nowhere."

If you want to see how the privacy angle plays out across the specific tools, the PDF toolkit covers the five most-used PDF operations, the image toolkit covers the common photo formats including HEIC, and the formats glossary explains when each format is appropriate in the first place.

Other credible privacy-respecting options exist:

PDF24's desktop installer runs locally (web version does not).
Pandoc on the command line is the gold standard for format conversion for anyone comfortable with a terminal.
Preview.app on macOS converts most Apple-native formats without any third-party involvement.

The point is less which tool you pick, and more that in 2026 there's finally a real menu of options that don't require uploading your document in the first place.

Why this matters more in 2026 than it did a decade ago

Two things changed:

1. Generative AI companies are paying for document corpuses. Many smaller free-converter services have been acquired or are quietly licensing their uploaded-file streams to AI labs. This isn't conspiracy — it's in the acquisition press releases. The PDFs you uploaded to Random Free Converter in 2019 may now be in a 2026 training set.

2. Breach disclosure laws have tightened. The threshold has moved from "if we think we lost PII" to "if we think a document in storage might have contained PII." Every free file converter is now a potential breach-notification event — not just for them, but for every user whose document briefly lived on their infra.

The simplest way to opt out of being a line in a future breach notification is to not be in the dataset at all.

The simplest way to not be in the dataset is to never upload the file.

That option has existed in the browser for about two years. Hardly anyone uses it yet.

TL;DR

Every big "free PDF converter" uploads your file. DevTools proves it.
The upload isn't needed — it exists to enable rate-limiting the free tier.
WebAssembly + big tab memory + File System Access API killed the need for server-side conversion for ~90% of operations.
The 1-hour deletion promise is weak against acquisitions, backups, interception, and breaches.
For sensitive docs (legal / medical / financial / ID), use a converter that runs in-browser.

If this was useful, give it a 💾 and share with the next dev you see googling "pdf to word online."

— Saroj GT, maintainer of FileConverterTools

DEV Community: Saroj GT