The old model: your file takes a round trip
A traditional conversion site is a courier service. Your video travels over the network to the operator's server, software there converts it, and the result travels back. The model works, but everything notable about it follows from that round trip. The upload itself can take as long as the conversion for large files. The server does real work per user, which is why such sites meter file sizes, queue jobs, and sell subscriptions. And — the part that matters most with personal footage, work material, or anything under an NDA — a complete copy of your file exists on someone else's computer, governed by a privacy policy you have to take on faith: how long copies are retained, who can access them, what happens if the operator is breached.
The new model: the converter comes to you
The alternative flips the direction of travel. Instead of your file going to the converter, the converter — the actual conversion program — is downloaded to your browser and runs there. Your file goes from your disk into your browser's memory, is processed on your own CPU, and is written back out as a download. The network is involved only once, to fetch the tool itself.
Two browser technologies make this possible. WebAssembly (Wasm) is a way to run compiled programs — real, existing software written in languages like C — inside a browser at near-native speed, in the same security sandbox that contains every web page. It arrived in all major browsers in 2017 and quietly powers things like Google Earth, Figma's design engine, and in-browser Photoshop. The heavy lifting in Mediamorphy is done by FFmpeg — the same open-source media engine that underpins VLC, YouTube's processing pipeline, and most conversion software on earth — compiled to WebAssembly and running entirely in the page. This is not a lightweight imitation of a converter; it is the industry-standard converter, relocated.
The File API completes the picture: when you pick or drop a file, the page gets permission to read it locally into memory — nothing about picking a file implies uploading it. Upload only happens if a site's code explicitly sends the data somewhere, which is precisely what this architecture never does.
"Never uploaded" is verifiable, not a promise
The strong version of this privacy claim is that you do not have to trust it — you can watch it be true. Every desktop browser ships developer tools that show all network traffic a page generates:
- Open the converter page, press F12, and select the Network tab.
- Convert a file and watch the request list. You will see the page's assets and the converter engine being downloaded (a one-time ~30 MB fetch, cached afterwards) — and no request carrying your file anywhere.
- For the definitive test: load the page, disconnect from the internet entirely, and convert. It works, because nothing about the conversion needs a network.
That offline test doubles as the cleanest mental model of the whole architecture: an upload-based converter without internet is a broken page; an in-browser converter without internet is still a converter.
The honest trade-offs
Running inside a browser sandbox imposes real costs, and it is worth knowing them up front rather than discovering them mid-task.
| In-browser (Wasm) | Upload service | Desktop app | |
|---|---|---|---|
| File privacy | Never leaves device | Server copy exists | Never leaves device |
| Install / signup | None | Usually account + limits | Installation |
| Speed on big jobs | Slower (single-thread) | Fast servers, slow upload | Fastest |
| File size ceiling | ~1–2 GB (browser memory) | Plan-dependent caps | Disk-limited |
| Works offline | Yes, once loaded | No | Yes |
The two limits worth respecting: memory — the file is processed in browser memory, and the engine can address at most about 2 GB, so multi-gigabyte sources are desktop-app territory; and speed — the sandboxed engine runs single-threaded, so a long 4K encode that a desktop FFmpeg finishes in minutes may take several times longer. For the everyday cases — converting a recording, extracting audio, shrinking a clip to send — the difference is a coffee's worth of patience in exchange for the file never existing anywhere but your own machine.
Why this model is winning
Hardware did most of the work: the laptop or phone you already own is enormously faster than the fraction of a shared server an online service can afford to give you for free, so shipping the program to the data has become more sensible than shipping the data to the program — especially when the data is a gigabyte of video and the program is a 30 MB download. Privacy, cost, and offline capability all fall out of the same architectural choice. Upload services still earn their keep on huge files and heavy batch work; for everything else, the converter that comes to you is simply the better deal.