Encrypted, but still readable

The pitch is easy to like. You dictate a sentence, change your mind halfway through, and the software is supposed to keep up with you. "Meet at 2, actually 3" comes out as "Meet at 3." Wispr Flow markets this as Backtrack, a feature that reads your rambling, your pauses, and your mid-sentence corrections and returns the thought you landed on rather than the one you abandoned. It is a genuinely useful idea. The question worth asking is where that understanding happens, and what has to travel for it to work.

A word before we go further. This is not a case against using Wispr Flow. It is a capable product with real engineering behind it, and for many people the convenience is worth the trade. Our point is narrower, and we think more useful. You should be able to see where your words actually go, and how they are protected once they arrive, because those details are not always what the marketing language implies. Not all encryption is equal, and knowing the difference is the difference between an informed choice and a comfortable assumption.

How it actually works

We took Wispr Flow's client apart by reading it, statically, without sending a single request to Wispr's servers. Wispr Flow is an Electron application whose core logic is shared across platforms, and what we read was that shared client core - the same core that ships inside the Mac build. The formatting pipeline described below was recovered from that cross-platform code and is consistent across the Windows and macOS builds we examined. A few things are settled by that reading, and one important thing is not, so we will keep the two apart.

What is proven Wispr Flow is a thin client. The audio you speak is streamed to Wispr's servers, where transcription happens, and there is no on-device speech model doing the first pass. Every step of cleanup that follows - removing "um" and "uh," adding punctuation and capitalization, and any reshaping of what you said - is a network request to a backend endpoint, /llm/formatting, that returns the server's answer as the text you see. We searched the entire client for a local list of filler words or any correction logic. There is none. There is no on-device language model in the client at all. The formatting always requires the round trip.

What is inferred The word "Backtrack" appears on Wispr's marketing pages and never in the client's code, and there is no code path by that name. The most reasonable reading is that the marketed Backtrack behavior is produced by a server-side language model on their backend, the same model that rewrites your transcript into a clean result. We want to be precise here. We never intercepted a request labeled Backtrack, and the server's own instructions to that model cannot be recovered from the client. So the mechanism is an inference from how the pipeline is built, and we are stating it as inference on purpose.

What leaves the machine, and why

The reason this matters is what the formatting request carries. Cleaning up "meet at 2, actually 3" from the words alone is easy. The harder corrections are not: a misheard name, a term of art, a choice between two phrases that sound almost the same. Those can only be resolved with context, so the request sends more than your transcript.

Recovered from the client, that extra context is substantial. It includes the name of the app you are dictating into, and the web address it is showing. It includes the text around your cursor, and the accessibility text of the field you are typing in. When screen capture is switched on, it includes text read off your display by optical character recognition. And it includes your custom dictionary and your personal style settings.

The app does not stop at sending. After it pastes, it watches the text box, reads back the words you fixed by hand, and learns from the difference. Those learned words then sync to Wispr's servers. By Wispr's own documentation, that dictionary syncs regardless of Privacy Mode.

That is the honest shape of it. The feature sold as understanding you better works by sending more of your raw words and your screen away, because that is what the model on the far end needs to settle the ambiguous cases.

The privacy concerns, briefly

• Your audio always leaves the machine. There is no offline path in Wispr Flow, and the cloud round trip is mandatory for every dictation.
• The formatting request carries screen context, not only speech. That means the active app, the surrounding text, accessibility text, and OCR when it is on.
• Correction learning is a data pipeline. Your hand edits are read back through the accessibility interface, and when auto-learn is on, newly-introduced proper nouns are turned into synced dictionary entries.
• Privacy Mode is narrower than the name suggests. By Wispr's own definition it governs only whether your dictation is used to train models. The custom dictionary is exempt, and that is where auto-learn stores the proper nouns - names, brands, project codenames - distilled from your corrections. Those still sync to Wispr with Privacy Mode on.

Encrypted at rest, and who holds the key

Wispr's documentation uses the right words. In transit, "All confidential data in transit uses TLS 1.2 or higher with forward-secrecy cipher suites." At rest, "Stored data is encrypted with AES-256," with keys "managed in a hardware-backed key management service." (Security and Compliance FAQ, read 30 August 2026.) That is real protection and worth having. It also answers a narrower question than it appears to.

This is where the word "encryption" does more work than it should, because it covers two very different guarantees. Encryption protects your data from whoever does not hold the key. When the provider holds the key, as here, the encryption protects you from a stolen disk and from an outside attacker, and it does not protect you from the provider, who can decrypt at will. A zero-knowledge design is the other guarantee entirely: the provider stores only ciphertext it has no way to open. Both are honestly called encryption. They do not protect you from the same people, and that distinction is the whole game.

"Encrypted at rest" protects a stolen server disk. It says nothing about whether Wispr itself can read your data. On that, the same FAQ is refreshingly direct:

The keys are Wispr's, and customer-managed keys are "not currently supported." The FAQ adds that when Cloud Sync is on and Privacy Mode is off, "A limited number of engineering and infrastructure personnel hold read-only, MFA-gated, logged production access." So the encryption is a lock against outsiders and stolen hardware. It is not a lock against Wispr. Whoever holds the key can open the box, and here that is the company, not you.

There is one setting where the content is genuinely out of reach. With Privacy Mode on and Cloud Sync off, "decrypted audio and transcripts are never persisted." But recall the dictionary. It syncs regardless of Privacy Mode, it is retained, and it sits under Wispr's keys, so even in the most private configuration the proper nouns distilled from your corrections stay readable by Wispr.

This is the distinction Privt is built on. Your notes and your vocabulary are encrypted on your Mac under a key only you hold, and what reaches us is ciphertext we cannot read. When we say encrypted at rest, we mean we could not open it if we wanted to, which is a different promise from choosing not to.

To be clear, Privt is not a cloud-free product. Your notes and vocabulary sync and back up to the cloud too. The difference is what the cloud receives: with Privt it is only ciphertext, sealed on your Mac before it ever leaves. Here is how the two approaches line up on the two things this post is about.

	Wispr Flow	Privt Voice
Encryption	Encrypted at rest with AES-256, but not end-to-end, by their own documentation	End-to-end and zero-knowledge, sealed on your Mac
Who holds the key	Wispr. Customer-managed keys are not supported	Only you
Does it use the cloud	Yes, for every dictation: audio, transcript, and on-screen context	Yes, for sync and backup, but only as ciphertext we cannot read. The dictation itself is processed on your Mac
Word learning	Your corrected names are learned and synced to Wispr, regardless of Privacy Mode	Learned from your own edits on your device; the dictionary is sealed and zero-knowledge synced, so we never see the words

Privt's alternative, and the honest trade

Self-correction can run without any of that. Privt Voice runs on Apple's on-device language model, the same one it already uses for your meeting summaries, so a correction like "actually 3" can be resolved on your Mac. Your audio, your transcript, and the surrounding context stay where they were spoken, and nothing is uploaded to be cleaned up.

Wispr Flow

Your words travel to Wispr's servers, and the cleaned text comes back.

Privt Voice

The correction is handled on your Mac, and nothing leaves it.

We will not oversell it. A model running on your laptop is smaller than one running in a data center, and on the most ambiguous corrections - a rare name it has never encountered, a garbled phrase that needs heavy context - a large cloud model will sometimes land the rewrite where the local one does not. That is a real trade, and it is about capability on the hardest corrections, not privacy - on Privt nothing leaves the Mac either way. For the everyday "meet at 2, actually 3," an on-device model can handle it, without a round trip.

Where do you land

None of this is a verdict on any one app. Plenty of people will read all of the above and keep using the tool they like, and that is a perfectly reasonable choice once it is an informed one. The only thing worth resisting is the comfortable assumption that "encrypted" means "unreadable," or that a correction made out loud stays with you. Know where your words go and who can read them, and then decide.

Which side of that trade would you take? We are running a community poll on exactly this question, whether you would give up a little cloud polish on the rare hard correction to keep every word on your own machine. Weigh in, and tell us where the line sits for you.