Ask whether an online file converter is safe and you’ll get the same answer everywhere: look for HTTPS, check that they delete files afterwards, avoid sketchy sites. All reasonable. All beside the point.
Those answers quietly assume the file gets uploaded, and then argue about how well it’s guarded afterwards. But uploading isn’t a requirement of converting a file — it’s an architectural choice, and a growing number of tools don’t make it. So the useful question isn’t “do I trust their retention policy?” It’s the much simpler, much more checkable: did my file leave this computer at all?
You can answer that yourself in about a minute, without taking anyone’s word for it. Here are three tests, from most rigorous to easiest, and what we measured when we ran them on our own tool.
First: there are two completely different things called “online converter”
They look identical — a web page, a drop zone, a download button. Underneath they’re opposites.
| Server-side | In-browser (local) | |
|---|---|---|
| Where the work happens | Their machines | Your machine |
| Your file | Uploaded, stored, processed, deleted on a timer | Never transmitted |
| Wait before work starts | Full upload time | None |
| Why there’s a size cap | Bandwidth and CPU cost them money | Only your device’s memory |
| Privacy rests on | Their policy and their security | Nothing leaving in the first place |
| Typical free-tier limit | 100 MB – 1 GB | Multi-gigabyte |
This is why the tests below work at all. The two designs leave completely different fingerprints, and neither can hide them.
Test 1: Watch the network tab (the rigorous one)
Your browser will tell you exactly what it sent. Nobody can spoof this — it’s your own browser reporting on itself.
- Open the converter, then press F12 (or Cmd+Option+I on a Mac) and click the Network tab.
- Click the clear button to empty the list.
- Now add your file and run the conversion.
- Sort by the Size column, largest first, and look at the biggest outgoing request.
If it uploads: you’ll see a POST request roughly the size of your file. A 200 MB video produces about 200 MB of outgoing data. It cannot be smaller — the bytes have to physically get there.
If it’s local: the largest outgoing request will be kilobytes. There is nowhere for a 200 MB payload to hide.
One false positive to know about
You will very likely see entries starting with blob:, sometimes with a large size and a 206 status. That is not an upload. A blob: URL is a local handle to data already in your browser’s memory, and the browser lists it in the Network panel because it’s a “fetch” in the technical sense. Nothing crosses the network. Local tools generate a lot of these — it’s a sign of local processing, not against it.
The entries that matter are ones with a real hostname and a request payload.
Test 2: The stopwatch test (no tools needed)
Uploads obey physics. Your home internet’s upload speed is usually far slower than its download speed, and a file cannot be processed on a server before it has finished arriving.
| Your file | Minimum upload time at 10 Mbps up | At 50 Mbps up |
|---|---|---|
| 100 MB | ~80 seconds | ~16 seconds |
| 1 GB | ~14 minutes | ~3 minutes |
| 4 GB | ~55 minutes | ~11 minutes |
So: drop in a large file and watch what happens in the first few seconds. If a progress bar for the actual conversion starts moving immediately on a 2 GB file, no upload occurred — there wasn’t time. If you sit through a long “Uploading…” phase before anything else happens, you have your answer, and it was honest about it.
This is also the practical reason local tools handle big files at all. A site paying for bandwidth has to cap you; a tool using your own CPU has no such bill.
Test 3: Cut the network mid-job
The bluntest test: take the internet away and see if the work continues.
The sequencing matters, and most write-ups of this test get it wrong. Modern web apps load code in pieces, so the conversion engine may not download until the moment you actually select a file. Disconnect too early and you’re testing whether the page finished loading, not where the processing happens.
Do it in this order:
- Open the page and select your file. Wait until the tool shows it’s ready to go.
- Now turn off Wi-Fi or pull the cable.
- Start the conversion.
A local tool runs to completion and hands you the file. A server-side tool stalls or errors out, because the thing doing the work is no longer reachable.
What we measured on our own tool
It would be a bit much to publish these tests without running them on ourselves. So we did, with the browser’s own network log as the instrument.
We fed a 4.19 MB MP4 into the video compressor on this site and recorded every outgoing request from the moment the file was selected until the download was ready.
- Total outbound data: 1,325 bytes. Two Google Analytics beacons — 311 bytes and 1,014 bytes.
- Bytes of video sent: zero. The largest request body in the entire run was one kilobyte.
- During the encode itself, requests to our own domain: zero. Not a single one while the progress bar was moving.
An accidental detail makes the point better than we’d have managed on purpose: during the test, those analytics beacons actually failed — our own host returned a 503 for them. The compression finished anyway, at full speed. The pipeline doesn’t just avoid sending your file; it doesn’t depend on the network at all once it’s running.
Two things we want to be straight about. First, yes — there is analytics, and there are ads on the page. That’s how a free tool with no signup and no upload cost stays free. What those beacons carry is page views and button clicks, not your file. Second, that 1,325 bytes is the honest full number, not “roughly nothing” — you can reproduce it with Test 1 in about a minute, and we’d rather you did.
The mechanism behind this isn’t exotic. The conversion runs as WebAssembly — a real build of FFmpeg compiled to run inside the browser tab, reading your file straight off your disk through the browser’s file API. We wrote up how that pipeline works in detail in How an In-Browser Audio Converter Actually Works.
What “we delete your files after 2 hours” actually buys you
Most reputable server-side converters do delete uploads, and most of them mean it. This isn’t an accusation. It’s about what kind of assurance you’re getting.
A deletion policy is a promise about something that already happened. Your file was transmitted, written to a disk you don’t control, and passed through logs, backups and whatever infrastructure sits in between. Keeping that promise depends on their retention actually working, their access controls holding, their vendors behaving and their company continuing to exist. Every one of those is probably fine. None of them is checkable by you.
A file that was never sent doesn’t need a promise. There is no copy to retain, breach, subpoena or forget about.
For a meme clip, the difference is academic — upload it anywhere. It stops being academic for the things people actually convert and compress: a signed contract, a passport scan, medical paperwork, an NDA’d client cut, unreleased footage, video of your kids. That’s also why we care most about it on the PDF compressor, which is where the genuinely sensitive documents show up.
Frequently asked questions
Are online file converters safe to use?
The mainstream ones are generally safe in the sense that they aren’t trying to harm you — the real variable is whether your file gets uploaded, and how much you care about that for this particular file. Run Test 1 above and you’ll know which kind of tool you’re using in about a minute, rather than relying on the marketing copy.
Does HTTPS mean my file is private?
No. HTTPS protects your file in transit, from people between you and the server. It says nothing about what happens once it arrives — who can read it, how long it’s kept, where it’s backed up. HTTPS is necessary, not sufficient, and it’s irrelevant to a tool that doesn’t transmit the file at all.
Why do most free converters cap file size?
Because every megabyte you upload costs them bandwidth, storage and CPU time. The cap is where the free tier stops being affordable, which is why it usually sits between 100 MB and 1 GB and why the paid tier raises it. Tools that run in your browser don’t have that cost, so their ceiling is your device’s memory instead — gigabytes rather than megabytes.
Can a website really convert video without a server?
Yes. WebAssembly lets real compiled code — including FFmpeg, the same engine behind most desktop video tools — run at close to native speed inside a browser tab. The page delivers the program; your own processor does the work. It’s the same reason a modern browser can run a video editor or a 3D game without installing anything.
Don’t trust it — check it
Every claim in this article, including ours, is verifiable from your own machine in under a minute. Open the network tab, drop in a file, look at the largest outgoing request. Do it to us, and do it to whatever tool you were about to paste a contract into.
If you’d like something to test it on, the video compressor, converters and PDF compressor here all run entirely in your browser — free, no signup, no watermark, and now you don’t have to take our word for it.

Fei is a skilled software engineer. He previously worked at Google and now at a startup. His expertise includes web media processing, cloud architecture, complex algorithms, and AI training and deployment. Beyond work, Fei enjoys diving into new knowledge and is a big fan of strategy games.
0 Comments
1 Pingback