Why privacy matters when converting audio files online

When you use a typical online audio converter, your file takes a round trip. It uploads to a remote server, something happens to it there, and a result comes back. The mechanics are invisible and the whole thing takes a few seconds, which is exactly why it rarely gets a second thought — until the file in question is an unreleased track, an interview recording, or something covered by a client agreement.

What actually happens on a server-based converter

The common pattern looks like this:

1. You choose a file on your device.
2. It uploads to the converter's infrastructure, in a data centre you have no visibility into.
3. The server decodes, converts and writes an output file.
4. You download the result.
5. Both files remain on that infrastructure until something deletes them.

For the duration of that process — and for whatever window follows it — your audio exists somewhere you do not control. A service that promises deletion after a fixed period is making a commitment about its own behaviour, which is a different thing from a property you can check.

Where that actually bites

• Unreleased material. A track uploaded for a format change sits on third-party infrastructure before anyone has heard it. A breach at the wrong moment is a release you did not plan.
• Voice recordings. Interviews, dictation and source material routinely contain things the speaker did not consent to hand to an unrelated company.
• Work under agreement. Engineers and studios frequently operate under confidentiality terms that a casual upload can quietly breach.
• Retention you cannot audit. Even where deletion is genuinely intended, backups, logs and caches are separate systems with their own lifecycles.
• Terms that grant a licence. Some services reserve broad rights over uploaded content. This is not hidden — it is in the terms, which is where nobody reads it.

None of this requires anyone to be acting in bad faith. It is a structural property of sending a file somewhere: once it has left, its safety depends on someone else's decisions.

How in-browser conversion differs

A browser-based converter removes the server from the chain rather than promising to behave well once your file arrives there:

1. You choose a file. It stays where it is.
2. The page loads a processing engine compiled to WebAssembly, which runs inside the browser tab.
3. The file is decoded and re-encoded using your own device's CPU and memory.
4. The result is written straight to your downloads folder.
5. Nothing is transmitted, because there is nowhere for it to be transmitted to.

This is how the converter on this site works. The distinction that matters is not that the data is handled carefully — it is that the data is never handed over in the first place.

What makes this possible: WebAssembly

WebAssembly is a binary instruction format that browsers execute at speed close to native code, which is what makes real audio decoding practical inside a tab. The relevant part here is not the performance but the execution model.

WebAssembly runs in a sandboxed environment — the same one JavaScript runs in — and the WebAssembly Community Group describes it explicitly as a safe, sandboxed execution environment that enforces the browser's existing security policies.[1] The W3C Core Specification is the normative statement of those properties.[2] In practice that means:

• It reaches your file system only through an action you take, such as choosing a file.
• It has no independent ability to open network connections and send your data somewhere.
• It works in memory, and that memory goes away when the tab does.

The important word is enforced. These are constraints the browser imposes on the code, not undertakings the site makes about the code. A company can revise a privacy policy; it cannot revise the sandbox. How WebAssembly changed browser audio tools goes further into the architecture itself.

How to verify any converter yourself

Claiming to be private is easy. Here is how to check, and it applies to this site as much as any other:

Four checks you can run in your own browser to distinguish local processing from an upload, and what each result tells you.

Check	How to run it	What it tells you
Network activity	Open developer tools, Network tab, then convert	Your audio appearing as an outgoing request means it is being uploaded
Offline test	Load the page, disconnect, then convert	If it still works, the processing is genuinely local
What the page loads	Look for a .wasm module in the network log	A local engine is being fetched, rather than a conversion endpoint being called
The privacy policy	Read it	A tool that never receives your files has little to describe; long data-handling sections imply data being handled

Scroll to see all columns

The offline test is the most decisive of the four, and it takes about thirty seconds. Our own privacy policy is short for the reason described above.

The bottom line

For a copy of a song you already published, none of this matters much. For anything confidential, unreleased or recorded on someone else's behalf, the difference between a policy and an architecture is the whole question. Prefer the tool where the answer to "what happens to my file" is that it never went anywhere — and then verify that for yourself rather than believing the sentence you just read.

Need to convert a file right now?

Free and private — your files are processed in your browser and are never uploaded. Up to 100 MB per file, 50 files per batch.

Convert MP3 to WAV