Search for a video converter and you’ll find a dozen sites in the first page of results. Nearly every one of them works the same way: you upload the file to their server, their server converts it, and you download the result. That “cloud conversion” flow has become so normalised that most users don’t think of it as an upload at all. It just feels like clicking Convert.

But it is an upload. And a video file is one of the more sensitive things you can upload without thinking.

#What actually happens on a “free online converter”

The honest sequence:

  1. You pick a file. Your browser reads it into memory.
  2. Your browser sends every byte of that file over HTTPS to the service’s server.
  3. The server writes the file to disk, runs FFmpeg (usually - server-side ffmpeg is the industry default), writes the output to disk, and stores it in an object store somewhere.
  4. You download the output.
  5. The service claims to delete both files after some period. There is no way to verify this claim.

Every ranking free converter runs this flow. Some cap free-tier file sizes at 200 MB (ezgif) or 1 GB (CloudConvert’s free tier) to keep bandwidth costs down. Some queue jobs during busy periods. Some run OCR on your video before converting, ostensibly for “content analysis.” All of them have your file bytes on disks they control, for at least the duration of the job and often longer. The privacy policy sets a retention window - “files deleted after 1 hour” is the common promise - but nothing you can inspect from your side confirms the deletion actually happened.

#How to prove a converter is uploading your file

You don’t have to trust anyone’s claim on this. Every browser ships a network inspector that shows exactly what data leaves your machine:

  1. Open the converter site in a fresh tab.
  2. Right-click anywhere on the page → Inspect (or press F12 on Windows / Cmd+Opt+I on macOS). Switch to the Network tab.
  3. Optionally tick “Preserve log” and filter for Fetch/XHR so you see only real requests.
  4. Drop your video file on the converter and start the conversion.
  5. Watch the Network tab. If you see an outgoing request whose payload size roughly matches your file size (allowing for HTTPS overhead), the file went to their server. If nothing of that size shows up, the conversion happened locally.

Do this test once and it becomes an easy habit. Most cloud converters show a very large POST to /upload, /api/convert, or an S3 pre-signed URL the moment you hit Convert. Local converters - Wave included - show only static-asset traffic and the WebAssembly runtime load; nothing outbound larger than a few kilobytes.

#Why this matters even for “boring” videos

Most people’s reflex is that it doesn’t matter much for a random screen recording or a phone clip. Fair enough. But three things stack:

  • Metadata leaks. Phone videos carry creation-time metadata and often GPS coordinates in the container atoms. Screen recordings sometimes capture notification banners, password-manager overlays, or private browser tabs reflexively. All of it travels with the file.
  • Third-party retention. Their privacy policy is a promise, not a guarantee. Data-breach incidents at file-hosting services have exposed uploaded content in the past. “Auto-deleted after an hour” isn’t the same as “never had a copy” - during that hour, anyone with access to the storage tier has the file.
  • The upload itself. A 500 MB file on a typical home connection is a real amount of your upload bandwidth and a real amount of time - several minutes at 20 Mbps up. And it’s wasted when the local machine could have done the same job in a fraction of the time without moving a byte.

#A different model: run the encoder in your browser

The technical prerequisites for browser-side video conversion took a while to land. FFmpeg had to be compiled to WebAssembly. Browsers had to allow that WebAssembly to run for long-running CPU work without hanging the page. Web Workers had to become universal. Standard file APIs had to reach the point where multi-hundred-megabyte reads didn’t crash the tab. WebCodecs - an API that hands web apps direct access to the browser’s hardware H.264 / HEVC encoders - had to ship in Chrome and Safari. By around 2023 all of that was in place; WebCodecs coverage got wide enough to lean on by 2025.

Which means: a video converter that runs entirely inside your browser tab is now viable, without a server involved anywhere. Wave (the site this article is on) is one implementation of the pattern:

  1. The page loads a WebAssembly build of FFmpeg into your browser (about 30 MB, once per session, cached after that).
  2. You pick or drop a video file. Your browser streams the bytes into the engine via a chunked WORKERFS mount - the whole file never has to fit into the WebAssembly heap at once.
  3. FFmpeg-in-WebAssembly, and (for H.264 output) the browser’s hardware WebCodecs encoder, do the conversion.
  4. You save the result to disk. The service side never had anything to send.

The mechanics of when Wave copies streams versus decodes and re-encodes them - the difference between a five-second conversion and a five-minute one - are covered in the remux-vs-re-encode article.

#The trade-offs

Local conversion has real trade-offs. Being honest about them:

  • File size ceiling. Very large files push against browser memory limits and may fail. Wave supports files up to 8 GB (with a warning above 2 GB); other browser-side tools sit around 1–2 GB. Cloud converters don’t care about this at all because they use the server’s memory, not yours. If your file is bigger than you need for the destination, see how to compress without losing quality for the honest bitrate-picking framework.
  • Encoder selection. Cloud converters can bundle GPL-licensed encoders like x264 without a licence problem. In-browser converters that care about license cleanliness stick to LGPL codecs or hand H.264 encoding to the browser’s WebCodecs API. For fast-copy remuxes this makes no difference. For actual re-encodes the browser’s hardware H.264 encoder is competitive with x264 at typical bitrates; the LGPL software fallback (used only on browsers without WebCodecs H.264) is a shade less efficient.
  • CPU is yours. The conversion uses your machine’s CPU (and GPU, via WebCodecs) rather than a server’s. On a modern laptop this is fast. On a low-powered device long clips take longer, and the fan may spin up.
  • No batch queueing. A local converter can’t hand you your file back later - you have to keep the tab open until it’s done. Cloud services can queue and email you when it’s ready.

The trade in return: your file never touches a server. There’s no upload delay, no queue, no privacy policy to trust, and no third-party server that has a copy of what you converted. The progress bar you watch is the actual conversion, not your upload speed.

#When cloud IS the right choice

Being honest about the other direction: there are cases where a server-side converter genuinely serves you better.

  • Files above 8 GB. A ProRes archive from a shoot, a 20 GB AVCHD dump, a full Blu-ray-quality remux - these push past what a browser can hold in memory. A server-side tool with tens of gigabytes of RAM handles them without complaint.
  • Very old or very underpowered hardware. A 2013 Chromebook with 2 GB of RAM can’t run WebAssembly ffmpeg fast enough to matter. On a server, the CPU work is somebody else’s problem; you just wait for the download.
  • Batch pipelines with dozens of files. Local browser tools handle one file at a time; a service with a queue API can rip through a folder overnight.

Outside those cases - which cover a small share of real conversions - local is faster, private, and free.

#Try it

The homepage on this site (wavemp4.com) converts videos and extracts audio locally. Common cases like MKV to MP4 and MOV to MP4 finish in seconds because they don’t re-encode at all - see why that container swap matters for iPhone playback. Formats that require a real re-encode (WEBM to MP4, WMV to MP4, VOB to MP4) take longer but still run entirely on your machine. And when you just want the sound, the MP4-to-MP3 extract uses the same in-browser pipeline.

Nothing gets uploaded. That’s not a marketing claim - there’s no server to upload to.