Skip to content

Transcribe Audio Without Uploading It Anywhere

Updated 2026-08-19

Most transcription services work the same way: you upload a file, their server transcribes it, you get text back. For a podcast episode that is about to be public anyway, fine. For a patient consultation, a legal deposition, an unreleased client campaign or a journalistic source recording, it is a problem — and often a contractual or regulatory one.

There is a second option that people do not realise exists: transcribing entirely inside your own browser, with the file never leaving your machine.

How local transcription works

Speech models like Whisper have been compiled to WebAssembly, a format browsers can execute at near-native speed inside their sandbox. That makes this sequence possible:

  1. You pick a file. The browser reads it from disk — no network involved.
  2. The audio is decoded and resampled locally using the Web Audio API.
  3. The model weights download once (about 74 MB) and are cached.
  4. Inference runs in a Web Worker on your CPU.
  5. Text appears. Nothing was sent anywhere.

Steps 1, 2, 4 and 5 involve no server at all. Step 3 is a one-time download of the model itself — which is a public file, identical for every user, and reveals nothing about your audio.

What this does and does not protect you from

It does protect against:

  • Your audio being stored on someone else’s infrastructure
  • Your audio being used as training data
  • A breach at the transcription vendor exposing your recordings
  • Cross-border data transfer problems (the file never crosses a border)

It does not protect against:

  • Malware on your own machine
  • Someone with physical access to your device
  • You then pasting the transcript into some other cloud service
  • A compromised browser extension reading the page

Local processing removes one specific and significant risk. It is not a complete security posture.

How to verify a tool is actually local

Vendors say “private” and “secure” freely. Both are compatible with uploading your file. Here is how to check for yourself, in about thirty seconds:

  1. Open DevTools → Network before you start.
  2. Load the transcription page and clear the request list.
  3. Pick your file and start transcribing.
  4. Watch what goes out.

If it is genuinely local, you will see model file downloads (.onnx, .bin or similar, tens of megabytes, on the first run only) and nothing else. No request carries your audio.

If it is not, you will see a POST with a request body roughly the size of your file. That is your recording leaving.

A stronger test: disconnect from the network after the model has cached, then transcribe. If it still works, the processing is unambiguously local. This is a claim that cannot be faked.

Our audio to text page passes both tests — that is the whole point of building it this way.

The tradeoffs, honestly

Local transcription is not strictly better. What you give up:

  • Speed on long files. Your laptop CPU is slower than a datacentre GPU. A two-hour recording takes meaningfully longer.
  • First-run wait. ~74 MB downloads before the first transcription starts. Cached afterwards.
  • Model size ceiling. Browser tools use base-sized models. Server tools can run large, which is better on difficult audio.
  • No speaker labels. Diarization usually needs a second model that is impractical in a browser.

If you are transcribing eight hours of conference audio that will be published anyway, a hosted API is the right tool. If you are transcribing a forty-minute interview with a confidential source, it is not.

Sector notes

Healthcare. Uploading identifiable patient audio to a service without a signed BAA is a HIPAA problem in the US, and comparable rules exist elsewhere. Local processing sidesteps the question — there is no disclosure to a business associate, because there is no business associate.

Legal. Client recordings carry privilege. Handing them to a third-party processor is at minimum a conversation with your firm’s risk team.

Journalism. Source protection is the entire job. A subpoena to a transcription vendor is a real attack path, and one you can remove entirely.

Agency and creative work. Unreleased campaign material under NDA usually cannot be sent to unapproved processors, and “I used a free web tool” is not a defence anyone enjoys giving.

What to do with the transcript afterwards

The weakest link is often what happens next. Transcribing locally and then pasting the result into a cloud document, a chat assistant or a translation site undoes the protection completely.

If the recording was sensitive enough to transcribe locally, the transcript is too. Keep it in the same trust boundary.

Common questions

Is browser transcription accurate enough for professional work? For clean single-speaker audio, yes — expect a solid first draft needing light editing. For overlapping speakers or poor recordings, expect to do real editing regardless of which tool you use.

Does the model download reveal my file? No. It is a public, identical file for every user, requested before your audio is ever read.

Can I use it offline? Yes, after the first run. That is also the cleanest proof that it is local.

Is there a file size limit? No server limit, since there is no server. The practical ceiling is your device’s memory — multi-hour files can exhaust it on a phone.

What about the enterprise plan of a cloud service? A signed agreement is a legal control. Local processing is a technical one. Technical controls do not depend on the other party keeping their word.

More guides