Key Takeaways
Yes, it is possible, but it is rarer than the marketing suggests. Transcription that runs on your device and transcription that runs on a server are two different builds, not a setting you flip, and most apps are the server kind because a local model costs storage and runs slower on older hardware. A privacy policy that promises encryption in transit is describing the connection, not the destination. Ask three things of any tool: does the audio leave the device, how long is it kept, and is it used to train anything.
If you are holding a recording of a therapy session, a call with a lawyer, or a meeting that was never meant to leave the room, the question is not academic. You want to know whether the file can become text without a copy of it landing on someone else’s hardware. The answer exists, and it is more specific than most product pages let on.
What follows is the honest shape of it: what runs locally, what does not, why the split falls where it does, and what to ask before you trust anything with audio you cannot take back.
On-device and server transcription are two different builds
The most useful thing to understand is that this is not a privacy preference an app grants you. Transcription that happens on your phone or laptop and transcription that happens on a remote machine are different architectures. An app was built one way or the other. There is no switch buried in settings that moves the work from a server to your device, because the pieces required for local processing either shipped with the app or they did not.
Local transcription means a speech model lives on your device. Your audio is fed to it there, the text comes out there, and nothing needs to travel. Server transcription means your audio is sent somewhere, processed on hardware you do not control, and the text is sent back. Both can be well built. Both can be badly built. But only one of them keeps the audio in your hands, and which one you are using is a fact about the software, not about how carefully you configured it.
The reason most apps take the server route is not indifference. A local model has to be stored on the device, which costs real storage. It runs on whatever processor the device happens to have, which means it is slower on older hardware and slower still on long files. Those two constraints are enough to push most products onto servers, where the model can be large, the hardware can be fast, and nothing has to be downloaded. That trade is the whole story of why the private option is the uncommon one.
Encryption in transit describes the road, not the destination
This is where a lot of reasonable people get a false sense of safety. A privacy policy states that your data is encrypted in transit. That sentence is almost certainly true, and it tells you nothing about whether your audio is processed on a server or stored there afterwards.
Encryption in transit means the connection between your device and the service is protected while the data moves. It is a statement about the road. It is entirely compatible with your audio arriving at a server, being processed there, and sitting in storage for as long as the retention policy allows. If anything, a promise about encryption in transit is quiet confirmation that something is in transit at all. Audio that never leaves your device does not need a protected connection, because it is not making a journey.
So when you read a security page, separate the claims. Protection of the connection is one claim. Where the processing happens is another. How long the audio is retained is a third. A page can be scrupulously honest about the first and simply silent on the other two, and you will come away believing something the page never said.
What a browser can genuinely do without sending your file
There is a real category of tools that process a file entirely in your browser. You open a page, choose a file, and the work happens in the tab. Nothing is uploaded. This is not a marketing framing; it is how the tool is built, and it means the file never leaves your machine.
The catch is what those tools can do. Browser-local processing works for tasks that need no model: converting between subtitle formats, shifting timings so captions line up with a re-cut video, counting words or characters in a transcript you already have. These are transformations of text and timing data. They are small, deterministic, and they need nothing but the file itself.
Turning speech into text is not that kind of task. It needs a speech model, and a model is a large thing that has to come from somewhere and live somewhere. A web page that offers to transcribe your audio is, in practice, sending that audio to a server to be processed. The page is the interface; the work happens elsewhere. If a browser tool transcribes, assume upload, and go looking for the retention policy rather than the reassurance.
The three questions that separate answers from marketing
You do not need to audit anyone’s infrastructure. You need three answers, and you need all three, because a good answer to one can hide a bad answer to another.
- Does the audio leave the device? Not “is it secure” and not “is it encrypted” – does it travel. A service that processes on a server should say so plainly.
- How long is it retained? If audio is sent somewhere, it is stored somewhere, at least briefly. The question is whether that is minutes, days, or until you ask for deletion.
- Is it used to train anything? Processing your audio and learning from your audio are different uses. A service can be honest about the first and vague about the second.
If a page answers only the first question, you have a third of the picture. If it answers none of them and offers encryption language instead, treat that as an answer in itself. Vagueness on retention is rarely accidental.
Applying that standard here: the SozAI transcription app runs on a server, so audio you record or upload is sent for processing, and the details of retention and handling are set out on the security and data handling page. The free subtitle and counting tools on the website are the part that runs entirely in your browser, and they do not transcribe.
Deleting the transcript is not the same as deleting the audio
This one catches people who did everything else right. You finish with a sensitive recording, you delete the transcript from the app, and the item disappears from your list. It feels finished.
The transcript and the audio are usually governed by separate retention rules. Removing a transcript from an app removes it from your view of the app. The audio that produced it lives with the service that did the processing, under whatever retention policy that service operates, and that policy may not be triggered by your tapping delete on a piece of text. The two deletions are different actions, and only one of them is in front of you.
So if the audio matters, look for the retention answer specifically, in the privacy policy or wherever a service documents it. Look for a stated period, or a stated mechanism for requesting deletion of the source file, not just the output. If you cannot find either, you have not found a policy that covers what you are worried about.
What you give up by insisting on local processing
If you decide that nothing leaves the device, full stop, that is a defensible position and there is a cost attached. Be clear about the cost before you commit, because the disappointment usually lands later, in the middle of a long file.
The model has to be on your device, so you pay in storage. It has to run on your device, so you pay in time, and that bill grows on older hardware and long recordings. A two-hour meeting is not a two-minute job on a phone that is a few years old. There is no way to buy your way out of this within the local architecture, because the whole point is that no faster machine is involved.
On accuracy, resist the urge to accept a general rule in either direction. What is genuinely knowable is that a local setup is bounded by what fits on the device and what the device can compute, and a server setup is not. Whether that shows up in your transcript depends on the model, the recording, the accents, the background noise, and the language. The only honest test is your own audio, on the tool you are considering, before you rely on it for something that matters.
And there is a middle path that people overlook: not every recording needs the same treatment. The therapy session and the standup meeting do not require identical handling. It is entirely reasonable to use a server-based tool for most work and keep a small set of recordings out of it entirely, transcribing those by hand or not at all. Deciding which pile a file belongs in is usually a faster route to peace of mind than searching for one tool that satisfies every case.
