Checking whether a converter really keeps your file local
They have something confidential — an interview, a client recording, medical dictation, unreleased music — and a row of sites all claiming to be private. They cannot tell the marketing from the mechanism, and the claim is now so common that it carries no information.
Two checks settle it, and you can run both in about a minute. Open your browser's Network panel and watch it while the conversion runs: a converter that sends your file somewhere has to make a request roughly the size of your file, and you will see it. Then disconnect from the internet after the page has loaded and convert anyway: if the job finishes with no network, no machine other than yours did the work. Nothing else counts as evidence. Not a padlock, not a trust badge, not a paragraph in a privacy policy. Those describe intentions; the two checks describe the mechanism.
Why the claim itself tells you nothing
Search for a private audio converter and every result says the same thing. "Your files are safe." "We respect your privacy." "Secure conversion." The wording has spread so widely that it now separates nothing from nothing, because two completely different architectures can both write it honestly.
- Server-side. Your file travels across the internet to a machine the company runs, FFmpeg runs there, and the result comes back down. The company may well be careful with it, and most are. But a copy of your recording existed on hardware you do not control, under a jurisdiction you did not choose.
- In the browser. The conversion code is compiled to WebAssembly and runs inside your own tab, on your own processor. There is no upload step, because there is nowhere for the file to go. The site could not read your recording if it wanted to.
Both can claim to be secure. Only one of them is checkable by anyone, which is the point of the two tests below.
Check one: watch the Network panel during the job
Every browser keeps a list of every request a page makes. It is the closest thing to a lie detector you have.
- Chrome or Edge: press
F12(Windows) orCmd+Option+I(Mac), then click Network. Tick Preserve log so nothing is cleared out from under you. - Firefox:
Ctrl+Shift+E, orCmd+Option+Eon a Mac, opens the Network Monitor directly. - Safari: Settings → Advanced → tick Show features for web developers, then Develop → Show Web Inspector and choose Network.
- Reload the page with the panel open, then pick your file, start the conversion and watch the list. Right-clicking the column headers lets you add a Method column, which makes a
POSTeasy to spot.
What a server-based converter looks like, and it is not subtle: a POST whose request size is roughly the size of your recording, usually as multipart/form-data, taking as long as your connection needs to push those megabytes out. Then a run of small polling requests asking whether the job is done, then a GET that pulls the finished file back. Click the big request and open the Payload tab in Chrome, or Request in Firefox, and your file is sitting in it.
What this site looks like: the page's HTML, one stylesheet and a few small scripts on arrival, then one large request for the conversion engine, all from this one domain. From the moment you press convert to the moment the file is ready, the list stops growing.
Check two: pull the plug and convert anyway
This one needs no jargon at all, and it is the one that actually decides.
- Load the converter page and wait for it to finish loading completely. On this site that means letting the engine download once — it is a 32 MB file, and it is cached for a year afterwards.
- Turn off Wi-Fi, unplug the cable, or switch the machine to aeroplane mode.
- Convert your file and save the result.
If a finished file lands in your Downloads folder while the machine has no connection, the audio was decoded and re-encoded on your own hardware. There was no route to anywhere else. A server-based converter fails at this step with a network error, which is not a criticism of it.
A page could in principle hold your file and send it once the connection returns, using a service worker and the Background Sync API. To rule that out, open Application → Service workers in Chrome, or about:debugging#/runtime/this-firefox in Firefox, and look for a registration. This site registers none at all. Second, working offline proves no server did the conversion; it does not by itself prove nothing was kept locally. Application → Storage shows you what a site has written to IndexedDB and local storage on your machine.
What each kind of evidence actually proves
Most of what converter sites offer as reassurance is real, and answers a question nobody asked.
| What you are shown | What it establishes | Worth |
|---|---|---|
| The padlock in the address bar | The connection is encrypted in transit. It says nothing about whether a file travels over it, or what happens at the far end | None, for this question |
| "We never look at your files" | A statement of policy by a company you cannot audit | Weak |
| "Files are deleted after a few hours" | That a copy exists for those hours, and that deleting it is a process rather than a certainty | Weak, and see below |
| Compliance badges and certification logos | How data is handled and documented. Not where it goes | Weak |
| The Network panel staying still through the job | Nothing left the tab while the work happened | Strong |
| The conversion completing with the network off | Your own processor did the work. There was nowhere else for it to happen | Decisive |
| No service worker and no stored copy in Application → Storage | Nothing is queued for later and nothing was kept behind | Closes the last gap |
"Deleted after a few hours" is a promise about a copy that exists
This line appears on nearly every server-based converter and it is usually true. It is also the wrong shape of assurance for anything sensitive. The moment a recording is transmitted, it exists somewhere else: written to a disk in a data centre, quite possibly replicated to a backup, and subject to that company's jurisdiction, that company's security, and whatever that company becomes after its next acquisition. Deletion on a timer is a policy running on someone else's schedule, not a property of the system. Policies change, buckets get misconfigured, and legal requests arrive.
Weigh that against what you are converting. A ringtone cut from a pop song is not worth a second thought. A client interview, a doctor's dictation, an unreleased master, or a voice note being kept as evidence in an HR or insurance matter is a different category, and for those the useful distinction is not "we promise not to look" but "there is nothing here to look at". Converting WhatsApp voice notes runs into this constantly, because so many people doing it are doing it for a dispute.
Where a server-based converter is genuinely the better choice
Running the work in a tab is not automatically the right answer, and pretending otherwise would be the same kind of marketing this page is arguing against.
- Very large files. A browser tab has roughly 2 GB of address space and audio needs about three times the file size in memory while it works. This site warns above 300 MB and refuses above 2 GB. A server has no such ceiling.
- Speed on a long job. The engine here is single-threaded WebAssembly, so a server with many cores will finish a two-hour re-encode sooner. Only a stream copy is near-instant here, because no encoder runs at all.
- Formats this build cannot write. Opus output is the honest example:
libopuscrashes this particular WebAssembly build, so it is not offered. Opus files convert in perfectly well. - Automation. If you need an API, a watch folder, or a thousand files converted by a script overnight, a service is the correct tool.
- A phone with very little memory. Safari gives a tab far less room than a desktop browser, and on an older iPhone the engine sometimes will not fit.
None of that applies to a 40 MB voice memo, which is what most people are actually holding.
What this site loads, and when
The full inventory, so you can hold it against what your own Network panel shows.
- On arrival: the page HTML, one stylesheet, and a few small JavaScript modules. All from this domain.
- When you open the converter:
ffmpeg-core.jsandffmpeg-core.wasmfrom/vendor/ffmpeg/0.12.10/. The wasm file is 32,232,419 bytes. It comes from this origin rather than a public CDN on purpose, because a CDN request would be the one outbound connection that made the promise arguable. It is marked immutable and cached for a year, so it arrives once. - During a conversion: nothing.
- Never: analytics, advertising pixels, third-party fonts, embedded widgets, or any JavaScript written by anyone else. The site sets no cookies and has no form to submit.
One response header is worth checking yourself, in the Network panel under the document request or with curl -I. The Content-Security-Policy sets connect-src 'self' blob:, which makes the browser itself refuse any outbound connection to another domain, and form-action 'none', so the page cannot post a form anywhere. Be precise about what that buys you: 'self' still permits a request back to this same domain, so the header alone is not the proof. It closes off every destination except one, and the two checks above close off that one. How it works has the rest of the engine's detail, and what a conversion costs in quality is the other question worth settling first.
On a phone the same property arrives by a different route. The recordings are already on the device, the Audio Converter app processes them there, and once it is installed it needs no connection and no 32 MB engine download over cellular. On a desktop, with the file already in front of you, the converter on this site is the shorter path.
The converter on the home page handles this. Free, no upload, no sign-up.