You can verify a "local-only" dictation tool actually stays local in about five minutes, with tools already on your system: nethogs to watch per-process bandwidth, or a temporary firewall rule that blocks outbound traffic while you dictate. If transcription still works with the network cut, the audio never left the machine. If it stalls or errors out, it was calling home.
This matters because "processed locally" is one of the most loosely used phrases in dictation marketing. Plenty of tools do on-device wake-word detection or noise suppression, then stream the actual audio to a cloud API for the transcription step itself — the part that matters most for privacy. The label isn't false, exactly. It's just describing the 10% of the pipeline that stayed on your machine.
Cloud speech-to-text isn't just a privacy question, it's an architecture question. Every phrase you dictate — draft emails, source code, patient notes, whatever you're typing — makes a round trip to someone else's server before it becomes text on your screen. That means latency on every sentence, a dependency on your internet connection to type at all, and your voice audio sitting on infrastructure you don't control and can't audit.
None of that is disqualifying on its own — plenty of tools are upfront about being cloud-based. The problem is tools that market themselves as private or offline while quietly shipping audio to a server anyway, because "local" tests well and few users check. A vendor's privacy policy is a promise. Your firewall log is a fact.
1. Watch bandwidth with nethogs. Install it (apt install nethogs or your distro's equivalent), run sudo nethogs in a terminal, and dictate a few sentences. Watch the process list. If the dictation binary shows any sustained upload beyond a few stray bytes, it's sending something. A well-behaved local tool should sit at effectively zero traffic during transcription — you're looking for silence, not a small number.
2. Cut its network access entirely with a firewall rule. This is the more convincing test because it doesn't rely on you spotting a blip in a live graph. Find the tool's process owner or use a cgroup/user-based rule, or simplest of all: disconnect Wi-Fi or unplug ethernet, then dictate. With Voxtty, for example, you'd press Alt+D, speak a paragraph, and watch it get typed into whatever app has focus — with faster-whisper doing the transcription on-device, this should work identically with the network dead as it does connected, because there's no API call in the transcription path to fail. If a tool degrades or errors with no network, that's your answer.
3. Inspect packets directly with Wireshark or tcpdump. For anyone who wants to be certain rather than reasonably confident, capture traffic on your primary interface while dictating (sudo tcpdump -i any host not 127.0.0.1 is a quick filter) and check for any outbound connections coinciding with speech. This also catches sneakier cases — a tool that batches audio and sends it after a delay, rather than streaming it live, which a quick nethogs glance might miss.
You can try this test yourself — try Voxtty free and run any of the three checks above while dictating; transcription keeps working with the network blocked, because the audio never has anywhere to go.
Passing an offline test proves the audio and transcription step stayed local. It doesn't prove other things you might also care about — whether the app phones home for license checks, update pings, or crash telemetry unrelated to your voice data. Read the tool's own disclosure for that; a one-off network test won't distinguish "sends your dictation to a server" from "checks for a new version once a day," and conflating the two isn't fair to a vendor that's actually being straight with you.
It also won't tell you anything about optional cloud features a tool offers on top of local transcription. Some dictation tools, including Voxtty, offer opt-in AI cleanup that sends the transcript text (not audio) to a cloud API to strip filler words — that's a deliberate, disclosed exception, not a leak, and it should show up in your capture only when that feature is switched on. If you see traffic with the feature off, that's the actual red flag.
Whisper-based transcription itself has its own honest limitations worth knowing separately from the network question — accuracy drops with heavy accents, overlapping speech, or noisy rooms, regardless of whether it's running locally or in the cloud. That's a model quality tradeoff, not a privacy one, and no firewall rule will fix it.
Pick whatever dictation tool you're currently using — or are considering — and run the simplest version of this test: turn off Wi-Fi, try to dictate a sentence, see what happens. It takes thirty seconds and tells you more than any privacy policy will.
Local-first voice dictation for Linux. Press Alt+D, speak, and your words land in whatever app has focus — nothing leaves your machine.
Try Voxtty free →