Does dictation software send your voice to the cloud?
How to find out for yourself, on any dictation app, in about five minutes — with airplane mode and a firewall monitor, rather than by reading a privacy policy.
Some dictation apps send your voice to a server and some do not, and you can find out which one you have in about thirty seconds without reading a privacy policy. Disconnect from the network — airplane mode on, Wi-Fi off, ethernet unplugged — and dictate a sentence. If text appears as it normally does, the speech recognition ran on your own machine. If you get a spinner, an error or silence, your audio was being sent somewhere else to be processed and it cannot get there now.
That single test settles the question most people are actually asking, which is where recognition happens. It does not settle everything: an app that recognises locally can still upload audio or transcripts afterwards, and an app that fails offline might be failing for an unrelated reason such as a licence check. Two further checks close the gap and take a couple of minutes each — watch the app’s outbound connections with a per-application network monitor while you dictate, and look inside the app bundle for a speech model file. What follows is how to run all three, and, more usefully, what each result proves and what it does not.
Test one: dictate with the network off
This is the highest-value test because it is nearly impossible to fake. With no network there is no third option: recognition either happens locally or it doesn’t.
- Open the app and make sure it has already been through first-run setup, so you are not accidentally testing a one-off download.
- Turn Wi-Fi off from the menu bar and unplug any ethernet adapter. If the machine is tethered to a phone, turn that off too.
- In a text editor, dictate a full sentence of at least ten or twelve words, including a proper noun or an unusual term.
- Watch what happens, and how quickly.
Run this before you cancel a trial or uninstall anything. It takes less time than finding the vendor’s FAQ and gives you a better answer.
Reading the result of test one
- Text appears normally, at the usual speed and accuracy: recognition is local. Audio cannot reach a server over a network that is switched off, so this is conclusive.
- Nothing happens, or you get a network error: recognition is remote, and your audio normally leaves the machine.
- Text appears but is noticeably worse, or handles only very short phrases: some apps carry a small local fallback and use a larger cloud model when they can reach it. Dictate the same sentence online and compare — if the online version is markedly better, there is a cloud path.
- The app refuses to start, or complains about activation: ambiguous, and the common false negative. A licence check that needs the network stops you reaching the dictation feature at all, which looks identical to remote recognition from outside. Reconnect, launch the app so it validates, then disconnect while it stays open and try again.
Test two: watching the connections
The offline test tells you where recognition happens and nothing about what the app does while the network is available, which is a separate question — an app can transcribe locally and still upload the audio, the transcript, or a record of your usage.
For that you want a per-application outbound firewall, which prompts you whenever a program opens a connection and shows the destination. On macOS the two widely used ones are Little Snitch, which is commercial, and LuLu, which is free and open source; both do the same core job here. The firewall built into macOS filters incoming connections, so it will not help.
Set the monitor to alert or interactive mode and use the app normally for a few minutes, with several dictations of different lengths. What matters is not whether the app connects to anything, since almost everything connects to something. It is which hosts it contacts, whether connections line up with you speaking, and how many bytes go out.
- A connection that opens when you press the dictation key and closes when the text lands, with outbound volume growing as you speak for longer, is audio leaving the machine. Speech is large; a version check is not.
- A single connection at launch, or one a day, carrying a few hundred bytes, is a licence or update check.
- Steady low-volume traffic while the app sits idle is usually analytics or crash reporting.
- Connections to a CDN or object store shortly after you dictate deserve a closer look — that is a plausible shape for uploading recordings in the background.
What a network monitor cannot tell you
It cannot show contents. Everything is inside TLS, so you see destination hosts and byte counts and nothing else; volume correlating with speech length is strong circumstantial evidence, not proof. It also cannot prove absence over time — an app that uploads nothing during a twenty-minute test might batch recordings and send them when the machine is idle, at next launch, or only on unmetered networks.
And a connection is not by itself evidence of anything bad. Update checks, licence validation, font loading and documentation links all produce outbound traffic from apps that never touch your audio. Network activity is the beginning of a question, not the answer to one.
If you would rather not install anything, macOS ships thinner versions of the same visibility: Activity Monitor’s Network tab shows bytes sent per process, and in Terminal, nettop shows live per-process throughput while lsof -i lists what is currently open.
Test three: looking for a model in the bundle
A speech model that runs locally has to be somewhere on disk, and it is not small — useful speech models run from tens of megabytes to well over a gigabyte. In Finder, right-click the app in Applications, choose Show Package Contents, and sort Contents/Resources by size; you are looking for one very large file, often with an extension like .bin, .gguf, .mlmodelc or .onnx. A quicker version from Terminal is du -sh on the .app itself — if the whole application is 12 MB, there is no speech model inside it.
Finding one proves the app is capable of local recognition. It does not prove it always uses it, and it does not prove nothing is uploaded; capability and behaviour are different claims, which is why this test comes third.
Not finding one is much weaker evidence than it looks, and this is the trap. macOS itself provides on-device speech recognition through the system Speech framework, with model assets managed by the operating system rather than bundled into apps. An application taking that route has no model in its own bundle and is still recognising locally. Test one handles that case correctly and this one does not.
Putting the three results together
- Works offline, no traffic correlated with speech, model present in the bundle: recognition is local and nothing suggests audio is leaving. That is about as strong a conclusion as you can reach from outside the software.
- Works offline, but traffic correlates with dictation: recognition is local and something is being sent anyway — possibly a sync feature you enabled, possibly telemetry. Worth chasing.
- Fails offline: recognition is remote. Everything after that is a question about retention and use, not about whether the audio travels.
- Works offline with degraded quality: there are two paths, and which one you get depends on connectivity. Find out which runs by default.
A negative result on any single test is never as strong as a positive one. Absence of observed traffic during one session is not absence of traffic, and your conclusion should be phrased to match the window you actually measured.
Questions worth asking afterwards
If your measurements show audio leaving the machine — a normal architecture, not a scandal — the useful follow-ups are narrow, and the documentation should already contain them. How long is audio retained? Are transcripts kept separately, and for longer? Is any of it used to train or evaluate models, and is that opt-in or opt-out? Which subprocessors handle it, in what jurisdiction? Running the tests first tells you which of those answers matter and gives you an independent check on them: policies describe intended behaviour, a packet capture describes actual behaviour, and when they disagree the measurement wins.
The same standard applies in both directions. Voicecape keeps working with the network off because the speech model ships inside the app bundle, and the only two connections it makes are a one-time licence activation and a daily version check — but you should not take that from a marketing page any more than from anyone else’s. Run test one on it. The full account of what it sends and the privacy policy set out what a monitor should show, which is rather the point: a claim you can go and check is worth more than one you can only read. For the engineering picture behind the two architectures, the on-device and cloud comparison covers what each approach buys and gives up.