How transcription in a browser actually works

There is a reasonable suspicion attached to any website that claims to run AI locally. Everything else does the work on a server, so what exactly is different here? This is the whole pipeline, step by step, with no mystery in the middle.

The model is a file, and it comes to you

Speech recognition here uses Whisper, the speech model OpenAI released and published under a permissive licence. It is not an API you call. It is a set of weights — a large file of numbers — plus a description of how to run them. Anyone can download it, and once you have it you can run it without asking anyone’s permission.

That is the part that makes local transcription possible at all. The version used here has been converted to ONNX, a portable format that runs in a browser, and quantized to 8-bit integers, which cuts the file size roughly four-fold at a small cost in accuracy. The default English model comes to about 81 MB; the smallest is 45 MB.

The first time you transcribe something, that file is downloaded to your browser and stored in its cache. Every run after that reuses it, including with the network switched off. There is no subsequent download and no “checking in” with a server, because there is nothing to check in with.

Why it is served in pieces

Cloudflare Pages, which hosts this site, refuses to serve any single file larger than 25 MiB. The smallest useful Whisper decoder is 30.7 MB. So the weights are split into chunks under the limit at build time, and the code that loads them stitches the pieces back together in memory before handing them to the runtime. If you watch the network tab you will see requests for files ending .part0, .part1 and so on. That is why.

From your file to numbers

When you drop a file in, the browser’s own media decoder opens it — the same code that plays audio in a <video> tag. That is deliberate: it means the format support you get is whatever your browser already has, which is why MP3, MP4, MOV, WebM, M4A, WAV, FLAC and OGG all work without this site shipping a single decoder of its own.

The decoded audio is then converted into exactly the shape Whisper expects:

1. Mixed down to mono. Multi-channel recordings are averaged, not truncated — so an interview with one speaker per channel keeps both voices.
2. Resampled to 16,000 samples per second. Whisper was trained at that rate. Higher-quality audio is downsampled and loses nothing the model would have used; roughly speaking, it works from about the information content of a good telephone line.
3. Turned into a spectrogram. The waveform becomes a picture of which frequencies were present at which moments — a log-mel spectrogram, in the jargon. This is what the model actually reads. It never sees your audio as audio.

Thirty seconds at a time

Whisper has a fixed appetite: 30 seconds of audio per pass. Longer recordings are cut into 30-second windows, and — importantly — those windows overlap. A word landing exactly on a boundary would otherwise be sliced in half and heard as two fragments by two different passes. With overlap, it is seen whole by at least one of them, and the results are stitched back together with the duplicates removed.

This is also why a transcript arrives progressively rather than all at once. Each window produces its text and its timings before the next one starts, so you can begin reading the beginning while the end is still running.

Where the computation happens

The model runs through ONNX Runtime Web, compiled to WebAssembly. That is ordinary code running in the same sandbox as any other script on the page — it cannot read your disk, cannot open a network connection you did not initiate, and disappears when you close the tab.

If your browser supports WebGPU (recent Chrome and Edge), the heavy matrix arithmetic is handed to your graphics card, which is several times faster. Everything else falls back to the processor, using multiple threads where the browser allows it. Both paths produce the same transcript; only the waiting differs.

Because this is genuinely your hardware doing the work, speed depends on your machine and on the model you picked, and there is no queue and no rate limit. A ten-minute recording on a modern laptop with the small model finishes in a couple of minutes. The same file on the multilingual model takes noticeably longer. Nobody is metering it either way.

Where it does not happen

There is no server. This site is a folder of static files — HTML, CSS, JavaScript and the model weights — sitting on a CDN. There is no endpoint that accepts a file upload, because no such code exists in the project. That is a stronger guarantee than a privacy policy: a policy is a promise about what will be done with data that has already been sent, whereas here the sending step is absent.

You can confirm it in about thirty seconds, and the verification guide walks through how. The short version: open the network tab and transcribe something, or just disconnect from the internet after the model has cached and watch it keep working.

What this costs you

Honesty requires the other side of the ledger. Running locally means:

• A download before the first transcript. 45–81 MB, once.
• Smaller models than the cloud uses. Nobody is going to download a multi-gigabyte model to transcribe a voice note, so this ships base-sized checkpoints. On hard audio, the large models behind paid services genuinely do better — see how accurate is it, really.
• Your laptop’s speed, not a datacentre’s. On an old machine without WebGPU, a long recording takes a while.
• Your memory as the limit. The decoded audio has to fit in RAM, which is what constrains very long files rather than any imposed cap.

For a public podcast, those trade-offs may not be worth it. For a recording you are not allowed to hand to anyone else, they are the entire point.