Whisper Tiny, Base and Small in a browser

Start with the smallest useful trial

Tiny is a practical first test because its downloaded weights are smaller than those of Base or Small in the configurations used here. That does not mean Tiny is sufficient for every language or recording. It means you can check decoding, model loading and the basic review workflow before committing to a larger download.

Select a passage with the difficult features of your material: names, quiet speech, a change of speaker or the background sound you cannot avoid. Compare the same passage with another model if the draft needs too much correction. A simple introductory sentence is a poor stand-in for the rest of a challenging interview.

Published results describe a particular experiment

The original Whisper paper evaluates models across several datasets and languages. The model-size trend is useful, but it is not uniform across every row. Some low-resource language results are very poor even when the model is larger. A language option in the interface is not evidence that the resulting text will be reliable.

MurmurScribe shows those original paper values in its language pages. The app uses ONNX conversions with selected numerical precisions. Those configurations are not identical to the original research environment. We do not relabel the paper’s numbers as measurements of this product. If you need a quality estimate for a real job, test the actual runtime and recording.

Download size is configuration-specific

A Whisper model contains an encoder and a decoder. This app uses quantized versions for WebAssembly. Its GPU configuration keeps the encoder at full precision and uses a quantized merged decoder. The different file choices create different download totals even for the same model name.

The table below reports exact weight bytes from the Hugging Face file lists checked for the pinned model revisions. It excludes tokenizer files, configuration and runtime support files. The app displays decimal megabytes before starting. A rounded interface label is derived from the byte total, not a separately measured network transfer.

Quantization is a storage and computation choice, not an automatic guarantee of equal output. Hugging Face’s documentation specifically warns that some encoder-decoder models are sensitive to precision choices. That is why runtime validation and a representative sample both matter.

Memory includes much more than weights

The compressed file on disk is not the only allocation. The browser reads and decodes it into sample data. The model also needs intermediate arrays and state while generating text. Long recordings can require substantial memory even when their compressed source files look modest.

A download fitting into storage does not prove inference will fit into working memory. Closing unused tabs can help reduce competing load, but it does not make every model suitable for every device. If processing stops, return to Tiny, choose WebAssembly explicitly, or use a shorter recording that your device can handle. The app has no product minutes cap; the hardware still imposes a practical boundary.

GPU availability is a starting condition

WebGPU can make supported computation available through the browser. The presence of the API does not prove that a particular model will initialize successfully. Browser versions, drivers, adapters and resource limits can all affect the result. The automatic path tries GPU processing where available and falls back to WebAssembly when initialization fails.

WebAssembly uses the CPU and gives the product a path on browsers without usable GPU support. It may take longer, but no universal time multiplier is stated here. A benchmark from another laptop, browser or model precision would not establish your own processing time. The progress estimate in the app is based on completed chunks during that run.

Treat the cache as a convenience

The browser can cache model files after the initial download. This reduces repeated transfer when the same model revision is available locally. Storage eviction, private browsing and manual cleanup can remove those files, so the next run may need a connection again.

A cached model does not install the whole site as an offline application. Keep the page open if you are testing a disconnected workflow, and verify loading, inference and export before relying on it. For dependable repeated offline work, a dedicated local application may fit better.

Delete all local data in the app when you want to remove saved recordings and the model cache. Export transcripts first. Removing the cache does not delete documents already downloaded to a folder, and clearing a browser profile does not manage any separate device backups.

Worked example

For Tiny in WebAssembly, the sourced weight total is 40,844,231 bytes. Dividing by 1,000,000 produces 40.844231 decimal MB, displayed as 40.8 MB. This arithmetic does not include supporting files or predict runtime memory. If you compare Tiny and Base on an illustrative passage and Base requires fewer corrections, decide whether that improvement is worth its larger download on the device you will actually use. Record the model, task and language settings with your test so you can repeat the decision later.

Open the local transcriber to test an authorized recording and review the draft against the sound.

Keep a model-choice record that helps next time

After comparing a representative passage, save a small record with the exported transcript: the source file identifier, model, language, task and processing path. Note the errors you had to correct and whether loading completed reliably. This gives you a practical starting point for similar recordings without turning a single observation into a general performance claim.

Change one meaningful setting at a time when troubleshooting. If you switch the model, language, file export and browser together, you may get a better result without knowing which change helped. Begin by confirming the source decodes, then verify model loading, then inspect recognition. Keep those stages separate so a download problem is not confused with poor language quality.

If you use a larger model for a difficult passage, compare the whole sentence rather than counting only the word you hoped would improve. A correction in one place can coexist with a new error elsewhere. Pay attention to omitted speech and invented material as well as spelling. Readable output does not establish faithful transcription.

For repeated production work, reserve time to test after a browser or runtime update. The pinned model revision keeps the weights stable, but it does not freeze every part of the execution environment. If the old configuration stops working, retain the source and prior reviewed exports while you investigate. A change in runtime behavior should lead to a fresh practical check, not an assumption that a larger download will solve the issue.