Whisper model sizes compared: tiny, base and small in a browser

Parameters and download size are different numbers

A parameter is a learned weight inside the model. A download is a file you wait for. The two are related, but they are not the same measurement, and mixing them up makes a model decision look simpler than it is. The OpenAI repository lists tiny at 39 million parameters, base at 74 million and small at 244 million. The browser downloads in the table below are larger or smaller than a naive conversion would suggest because they include an encoder and a decoder, and because the runtime changes the numeric format.

This site serves an ONNX build through Transformers.js. On WASM it uses q8 weights, an 8-bit quantized format that reduces the download. On WebGPU it uses fp16, which is larger but suits the GPU path. Those are the two numbers a visitor actually experiences: the network transfer and the memory needed while the model is open. Neither number is an accuracy rating.

Whisper model sizes on Hugging Face: the measured downloads

The figures below were measured on 28 October 2026 by summing the encoder and decoder ONNX files in the onnx-community repositories used by this site. They are file sizes, not estimates from a parameter count. The tiny card, base card and small card document the repositories; the OpenAI README and paper document the architectures and parameter counts.

Whisper tiny vs base vs small in practice

The practical difference is not a clean staircase. Tiny is the quickest way to see whether a file is usable, and on a quiet close-mic recording it can produce a solid draft. It is also the most likely to smooth over a name, drop a repeated word or invent a plausible phrase in music. Base is the middle option: still small enough for a laptop, usually steadier on punctuation and ordinary vocabulary, and a reasonable default when you do not want to think about settings.

Small is the largest model this site offers. It has more capacity for accents, uncommon words and non-English speech, but it downloads more and takes longer. On a phone with limited memory it may fail or force the browser to reclaim tabs. The honest summary is that tiny, base and small are three points on a trade curve, not three grades of a product. A bigger file buys more computation, not a guarantee about your particular recording.

How browser constraints change the decision

A desktop transcription script can assume a large disk and plenty of RAM. A browser tab cannot. The model has to fit alongside the page, the decoded audio, the editor state and the rest of the user's session. WebGPU support is still uneven, and this worker falls back to WASM when a WebGPU model fails to load. That fallback is useful, but it means the same device may download a different file and run at a different pace than the first attempt suggested.

Mobile browsers are stricter about background tabs and memory. A small model that completes on a laptop may be terminated on an older phone, especially if the screen locks or the user switches apps. If the device is the constraint, choose tiny, keep the tab in the foreground and transcribe in shorter files. If the audio is difficult, move to a desktop before choosing small. The privacy page explains why this local processing is still a good trade for sensitive material.

How to choose a model for a specific job

Start with the job, then the device, then the audio. A quick social clip with clean speech does not need the largest model; a client interview with unfamiliar names does. A noisy field recording may benefit more from a better microphone than from another hundred million parameters. Run the same 30-second sample at two sizes and compare the edits you have to make.

1. Use tiny for a first listen when the file is long and you only need to find the usable sections.
2. Use base for a normal interview, lecture or tutorial with one clear speaker.
3. Use small when the speech is accented, non-English or recorded in a reverberant room, and the device has memory to spare.
4. Test on a representative clip before committing an hour of audio to a slow model.
5. Keep the model choice with the project notes so a later pass does not repeat the experiment.

Why the smallest model is sometimes the better editing tool

A fast model lets you iterate. You can run a sample, fix the language setting, adjust the audio and run again while the details are fresh. That loop often produces a better final subtitle than one slow pass with a larger model, because the editor catches systematic problems early. Tiny also makes it cheap to compare two microphone positions or two noise-reduction settings.

The caveat is that tiny's errors can be more fluent than obvious. A wrong name may look like a real name, and a missing clause may read smoothly. Use the small model as a second opinion on a short section when a line is important, rather than assuming that a fluent sentence is correct. The goal is a reviewable draft, not a model leaderboard.

Download, cache and offline behaviour

The first run downloads the selected model and stores it in the browser cache. Later runs reuse the cached files, subject to the browser's storage policy and available space. That is why the second transcription can start much faster than the first even though the model has not changed. If the cache is cleared, the browser evicts data under pressure, or the site is opened in a private window that discards storage, the download happens again.

Caching also explains the offline story. A page that is already open and a previously downloaded model can work without a network connection, but a model that was never cached cannot be fetched offline. The same applies to a model variant you have not used before. If you need a predictable offline session, load the exact model once while online, keep the browser profile, and test with the network disabled before relying on it in the field.

What we do not claim about speed

There is no honest universal transcription time. A ten-minute clip can finish while you make coffee on one machine and take long enough to abandon on another. The variables include the model, the runtime, the processor, the GPU, the browser, thermal throttling, the amount of silence and whether the tab stays in the foreground. A published "minutes per hour" number from a different device would not transfer to yours.

The same caution applies to memory. Parameter count gives a rough sense of scale, but the browser's overhead, the audio buffer and the decoded samples all contribute. Measure on the device you will actually use. If a run is interrupted, reduce the model or the file length before assuming the tool is broken.

Test the model on your own clip

Choose a one- to two-minute excerpt with the hardest conditions in the project: the quietest speaker, the most names, the music bed or the language switch. Run tiny and base, then small if the device allows. Compare three things: how many words you must retype, how often the timing needs correction, and how long the review takes. That comparison is more useful than a parameter table alone, because it measures the work you actually do.

If the results are close, keep the smaller model and spend the time on a careful review. If small is clearly better on the hard excerpt, use it for the final pass and keep tiny for the rough cut. The browser approach makes this experimentation cheap because the audio stays on the machine; start from the main generator or read the accuracy guide for the audio-side changes that often matter more than model size.