How transcription in the browser actually works
The model is Whisper, OpenAI's open-weights speech recognition model, in its smallest multilingual size. When you start a transcription your browser downloads the model files once — well under 100 MB — and caches them, then runs the model locally through WebGPU, the browser API that gives web pages access to your graphics hardware. On a device without WebGPU it falls back to WebAssembly and runs on the CPU instead, several times slower but with the same privacy properties.
The audio is decoded in the page, converted to the 16 kHz mono format the model expects, and fed through in windows so a long recording reports real progress instead of freezing the tab. The model returns word-level timings, which is where the timestamps come from. At no point is there a network request carrying your audio, because there is no endpoint in the page that accepts one — you can confirm that yourself in your browser's network panel while it runs.
What the privacy guarantee is, and what it is not
The guarantee is narrow and therefore worth something: your audio and the resulting transcript are never sent to OmniCanvas or to any third party, and we cannot see them, retain them, or be compelled to produce them, because they never arrive. The model download is the only network traffic involved, and it carries nothing about you but the request for the files.
What it does not mean is that your overall workflow is private by virtue of using this page. The file is still on your device, the transcript is still in your browser, and wherever you paste it next is governed by whatever rules apply there. Recording other people also has legal requirements that vary by jurisdiction and are entirely separate from where the processing happens. Treat this as a tool that removes one specific risk — the vendor holding your recording — rather than as a compliance control.
Why this matters for GDPR and data residency
A large share of searches for a private note taker come from people in Europe asking a question cloud services answer badly: where does the recording physically go, and who processes it. Under GDPR, sending a recording of a meeting to a transcription vendor makes them a processor of personal data, which means a data processing agreement, a lawful basis, a record of the transfer, and a real answer about sub-processors and international transfers. Many teams find that the paperwork costs more than the tool saves.
Local transcription removes the transfer rather than documenting it. If the audio never leaves the employee's laptop, there is no processor to contract with, no cross-border transfer to assess, and no vendor retention period to argue about. This is also why it tends to be the only workable option in settings where recordings simply cannot be sent out at all — clinical consultations, legal interviews, HR investigations, security incident calls, research under an ethics approval.
The honest caveat: this reduces your obligations, it does not eliminate them. The recording itself is still personal data in your hands, and consent, retention and access are still yours to manage.
Where cloud services are genuinely better
Accuracy. The hosted services run far larger models than anything that fits in a browser tab. On clean audio with a single clear speaker the gap is small — you will see a handful of errors per page. On heavy accents, crosstalk, technical vocabulary, a laptop microphone across a meeting room, or background noise, the gap widens noticeably. Nothing about running locally changes that; it is the model size.
Speed and scale. With WebGPU a recording transcribes several times faster than real time, so an hour-long file is minutes rather than an hour. On the WebAssembly fallback expect roughly real time. Either way you are using your own machine, so a batch of twenty interviews is a queue rather than a fleet of servers. Files here are capped at 45 minutes with WebGPU and 10 minutes without, and the page tells you when a file is over the cap instead of quietly transcribing part of it.
Speaker labels. This tool does not identify who is speaking. Diarization needs a separate acoustic model that we do not run locally, and guessing would produce a confident-looking answer that is wrong. If knowing which of five people said a thing is the point of the transcript, a hosted service will serve you better than this page will.
The alternatives people are usually comparing
Otter, Fathom, Granola and the rest of the AI notetaker category are built around a bot that joins your call, or an app that streams audio to their infrastructure. They are good at what they do, and the trade is explicit: your meeting audio lives on their servers under their retention policy. Hardware recorders like Plaud make the same trade at the transcription step. If that trade is acceptable for your meetings, those tools will out-perform a browser model.
The searches that bring people to a page like this one are usually the cases where it is not acceptable, or where a bot appearing in the participant list is itself the problem. For those, the realistic options are a local model like this one, a self-hosted Whisper instance, or writing notes by hand.
Getting the transcript somewhere useful
A transcript is a raw material, not an output. Copy it, download it as a text file, or export subtitles as SRT for a video — all without an account. Sending it to a canvas puts it next to the diagram, the tasks and the follow-up material from the same conversation, which is the format most people actually want a week later.
If it is the structure you want rather than the raw text, paste the result into the [AI meeting notes generator](/tools/ai-meeting-notes) to pull out decisions, action items and open questions — that one also runs in your browser. And if you want to know in advance how fast on-device models will run for you, [check your device](/tools/can-i-run-ai).