The same job, in two different places
Speech recognition is a piece of software running a model: a large file trained to turn sound into words. There is nothing mystical about it, and it has to run somewhere.
In the cloud, that file lives on a server. Your device records audio, sends it over the network, waits, and receives text in return. You never see the file and never think about it, and that is exactly the appeal.
Locally, the file lives on your own device. The audio never goes anywhere. Your phone or computer loads the model, does the work, and produces text without anything crossing a network.
That single difference is the whole of it. Everything else is consequence.
Three arrangements, not two
A third shape is common, and it is easy to mistake for either of the first two.
Plenty of products do both. They transcribe on the device when conditions allow and reach for a server when they want more capacity, more languages or more speed. Sometimes you choose; sometimes the software chooses for you based on your hardware, your language, or whether a component finished installing.
As engineering, this is sensible. You get the best available answer in each situation.
As a guarantee, it is weaker, and the distinction matters depending on why you wanted local in the first place. If you wanted it because your signal is unreliable, hybrid is fine: it will fall back and you carry on. If you wanted it because you would rather your voice was not transmitted, hybrid means the outcome depends on a state you have to keep track of, and states drift. Settings reset. Defaults change in updates. A language you start using is not covered locally.
Neither design is a trick. They are answers to different questions, and the only mistake is assuming one is the other. Two ends of a line are easy to describe. A great many products sit somewhere along it, and that is where most of the confusion comes from.
Where the extra capacity actually shows up
Cloud recognition can be enormous. A server has memory, cooling and specialist hardware, so the model can be far larger than anything that fits on a phone. More capacity generally means better handling of accents, background noise, unusual names and people who talk quickly. It can also be updated centrally, so it improves without you doing anything, and it can support very long lists of languages because size is not the constraint.
Local recognition is bounded by the device. On a phone that means a few gigabytes of memory shared with everything else, no fan, and a battery to protect. The model has to be small enough to load fast and finish before you lose patience.
So on raw capability, the cloud has the advantage, and that is not in dispute.
That advantage does not spread itself evenly over everything you might dictate.
Most people do not need the largest possible model. They need dictation that works in the moments they actually write: a reply on a train, a note in a shop, an email while walking. Those are short, clearly spoken sentences into a microphone held close to the face. For any modern model that is the easy case.
The hard cases, four people around a table with the microphone in the middle, heavy background noise, a recording of a lecture, are where server-side capacity genuinely wins. That is also work you are usually doing deliberately, with time to upload a file and wait.
Splitting it that way is more useful than picking a side: local for the writing you do all day, server-side for the recordings you are documenting on purpose.
Five things local hands back to you
It works without a connection. No signal, airplane mode, a basement, a foreign country with data switched off: none of them are special cases, because the network was never part of the process.
It fails differently. Cloud recognition tends to fail quietly on a poor connection. It waits, times out, or loses the sentence you just said. Local recognition either works or does not, and it works.
Latency is yours. Cloud speed depends on your connection and the load on someone else's servers. Local speed depends on your hardware and the model size you picked, which is at least a variable you control.
Your audio does not travel. This is the one most people are actually here for. If the recognition happens on your device, there is no upload, no server receiving your voice, and no copy of it anywhere else. That property comes from the architecture itself, not from a promise in a policy document.
No account is needed. Server-side processing usually implies identifying who is asking. Local processing does not.
The bill for running it on your own phone
Running the model on your own phone has a price, and it is paid in capability.
Storage. The model has to be on the device. Depending on the size you pick, that can be anywhere from tens to hundreds of megabytes, and on a phone that is already full it matters.
Memory while it runs. The model has to be held in memory during transcription, and older handsets struggle with the larger ones.
A smaller model. Accuracy against the best cloud services drops a little, especially with strong accents or noisy rooms.
Fewer languages. Multilingual capability costs size, so an on-device model covers fewer languages than a server-side one.
An initial download. The model has to arrive somehow, and that step needs a connection even though nothing afterwards does.
There is a sixth item that is easy to miss until you change phone. Local means your settings and your added vocabulary are on that handset, so an app that keeps them out of the cloud has nothing to restore from when you replace it.
Airplane mode, and the first-run download
Descriptions are unreliable, because "private", "secure" and even "offline" are used loosely. Two checks settle it.
Airplane mode. Install the app, let any first-run download finish, then turn off mobile data and Wi-Fi and dictate. If text appears, the recognition happened on the device.
Look for a model download. An app that transcribes locally has to get its model onto your device somehow, so it will tell you about a download of significant size. An app that never downloads anything but transcribes instantly is using someone else's hardware.
Be careful with one phrase in particular. "Your notes are stored locally" and "your speech is recognised locally" sound similar and mean completely different things. The first is about where the text is saved after the fact, and says nothing at all about where your voice went.
Where LocalType lands
LocalType sits on the local side of that line.
LocalType is an Android keyboard that does the recognition on the phone, with no cloud path in the app at all. It ships three model sizes, 60, 190 and 539 MB, so the storage and speed trade-off is yours to make rather than ours, and it covers eighteen languages from one multilingual model. On a test phone with 4 GB of memory the middle size turned 6.9 seconds of speech into text in 4.1 seconds.
That means it carries every cost listed above: storage, memory, a first download, a model smaller than a server could run. It asks for internet access for exactly one purpose, that first model download, and then leaves the network alone.
It also collects every item on the other list. No account to create. Nothing uploaded. No advertising in the product and no behavioural tracking inside it. No archive of your recordings, because audio becomes text and is done with. A model file in storage no other app can open, app data held back from Android's cloud backup on purpose, and no microphone key over a password field. Words you add by hand stay on the handset and are given to the model as context, so your own names come out right.
Whether that trade is the right one depends on what you write and where you write it. Somebody transcribing recorded meetings for a living and somebody answering messages on a train are not having the same argument.