The transcript gets written on the same machine that made the recording.

Most notetakers turn a recording into a transcript by sending the audio somewhere else and getting text back. This is the version where that step doesn't happen — where transcription runs on the Mac itself, and the recording never has to leave it to become readable text.

What "without uploading" actually means, step by step

It's not one setting to toggle; it's the shape of the whole process. Recording, transcription and the written summary all happen on the same machine, in that order, without any point where the audio is handed to a server and something is waited on before continuing.

Step 1 — record the meeting locally

Transcription starts from a recording that already exists on the Mac — the microphone and the call's own audio, captured as two tracks. Nothing about this step involves a network call; it's audio being written to a file the same way any recording app writes one.

Step 2 — transcription begins while the meeting is still running

Rather than waiting for the recording to finish and then sending the whole file somewhere, transcription works segment by segment as the conversation happens, using processing built into the app rather than a request to a server. By the time the call ends, most of the transcript already exists.

Step 3 — no key, no account, nothing to configure

There's no API key to obtain, paste in or renew, and no account to create before this works. Do I need an API key for transcription covers why that's a meaningful difference from tools built around a third-party transcription service — this one doesn't call out to one at all.

Step 4 — the summary is written locally too

Once the call ends, a language model bundled with the app turns the transcript and any notes taken during the meeting into a short set of minutes. That's the step most cloud tools genuinely need a server for; here it happens on the same Mac, without a second upload after the first one never occurred.

A practical way to check this yourself

The clearest proof that nothing is being uploaded is to disconnect the Mac from the network partway through a recording and keep talking. A tool that depends on a server for transcription stalls or queues audio the moment the connection drops; one that doesn't keeps writing text the whole time, because there was never a connection the transcript depended on to begin with.

Why this matters beyond speed

The case for doing this locally isn't that it's necessarily faster than a server — a fast connection can beat a slow local machine on raw throughput. It's that nothing has to be uploaded for the transcript to exist, which closes off three separate risks a cloud pipeline carries by design: audio intercepted in transit, audio sitting on a vendor's servers waiting to be breached, and audio used to improve a model that belongs to someone else. What local transcription actually is covers the underlying mechanism in more depth.

What still needs the network, and why

This isn't a claim that the app never talks to a server for anything. Licence activation needs the network once, and a launch-time clock check happens on every run — neither of those touches the recording, the transcript or the summary, all three of which are produced and stored entirely on the Mac regardless of whether either check has run recently.

How this compares to a cloud notetaker's version of the same step

A cloud tool produces a transcript too — the difference is what has to happen first. Sending the recording to a server before any text comes back means the transcript's existence depends on that upload completing, and on the vendor's own policies about what happens to the audio once it arrives there. Coii AudioNotes against Granola covers that trade in full; whether Otter trains on your data and the wider list of tools that don't train on recordings at all are worth reading directly rather than taking on faith, since the answer differs tool by tool and changes over time.

What this doesn't require you to trust

A vendor's privacy policy is a promise about how uploaded data will be handled. Not uploading the data at all removes the need to evaluate that promise in the first place — there's no server-side retention setting to check and no data-processing agreement to read, because the audio was never somewhere that either one would apply to it.

Working somewhere without a connection at all

Because the recording, the transcript and the summary are all produced locally, none of them depend on where the Mac happens to be — a flight, a basement conference room with no signal, a site visit somewhere without Wi-Fi. The fuller list of tools built to keep working with no server in the loop covers what that looks like across an entire meeting archive, not just one transcript.

What "on the Mac" actually means in practice

It's easy to hear "runs locally" as a vague marketing phrase rather than a specific claim, so it's worth being concrete about what's actually happening: the same processing that would otherwise be a request sent to a server, waited on, and answered with text, instead runs as part of the app itself, using the Mac's own processor while the recording continues. There is no server involved in that step at all — not a slower one, not a cheaper one, none.

Why cloud tools need the upload in the first place

It's worth understanding the other side of this honestly rather than treating it as an oversight. A cloud notetaker is built the way it is because running transcription centrally, on infrastructure the vendor controls, lets them improve the underlying process for every customer at once without shipping an update to each person's machine individually. That's a real advantage for a company operating at scale — the trade is that the audio has to leave the customer's device for the vendor to do it, every single time, for every single recording.

What changes about accuracy, if anything

Transcribing on the Mac instead of on a server isn't inherently more or less accurate — accuracy depends on the quality of the processing doing the work, not on which machine happens to run it. What changes is only the location of that work and what has to happen for it to run at all: nothing about the words being transcribed correctly depends on whether they travelled anywhere first.

Multiple recordings queued up on a busy day

Because there's no server request involved, transcribing several recordings from a single day doesn't compete for a shared queue the way it might with a service handling requests from many customers at once. Each recording is processed on the same Mac that made it, in its own time, without waiting behind anyone else's meeting.

What happens to a transcript once it exists

A finished transcript sits on the Mac as a file, alongside the recording it came from and the minutes generated from it — not synced to an account, not mirrored to a server for backup by default. That has a real consequence worth stating plainly: keeping it safe is the same responsibility as keeping any other file on the Mac safe, through whatever backup routine already covers the rest of the machine, rather than a vendor's infrastructure quietly handling that on your behalf.

The moment this matters most

The clearest case where this stops being an abstract preference is a recording that can't legally or professionally be sent anywhere else at all — a client conversation covered by confidentiality terms, a therapy session, a legal consultation. For those, "the audio never left the machine" isn't a nice-to-have property, it's the entire reason a tool is usable for the recording in question, regardless of how good any cloud alternative's own security might be on paper.

What this means for a Mac that's shared or lost

Because everything lives as files on the Mac rather than behind a separate cloud login, the actual security of a transcript ends up tied to the security of the Mac itself — whoever can unlock the machine can open the files on it, the same as any other document stored there. That's a different threat model from a cloud account, not an automatically safer one in every scenario, and it's worth keeping the Mac itself properly locked down rather than assuming "local" alone covers every angle.

Comparing this to a tool that offers an opt-out instead

Some cloud notetakers let a customer opt out of having their recordings used to improve the vendor's own models, as a setting somewhere in an account's preferences. An opt-out is still a setting that has to be found, understood and kept enabled correctly over time, on data that was uploaded regardless of whether that box was checked. Not uploading the audio at all removes the need to manage that setting in the first place, rather than trusting a preference to keep working correctly indefinitely.

A habit worth building before it's needed

The value of transcribing without uploading is easiest to underrate right up until a specific recording makes it obvious — the one call a client explicitly asks not to be sent to a third-party vendor, the one session a compliance policy flags after the fact. Building the habit of recording this way for everything, rather than switching tools only for the recordings that seem to need it, means there's never a moment of realising mid-call that the wrong tool is already running.

What this looks like for a team, not just one person

Each person's recordings, transcripts and minutes stay on their own Mac, across up to three machines on their own licence — there's no shared account where a colleague's local processing becomes visible to anyone else, because there's no account in the sense a cloud tool has one at all. A team standardising on this approach is really several people each doing the same thing independently, not a shared workspace with local processing bolted onto it.

Revisiting an old transcript without a connection

Because nothing about a finished transcript depends on a server having produced it, reading one back weeks later works exactly the same with the Mac offline as it does connected — there's no re-fetch from an account, no loading spinner waiting on a network response, just a file opening the way any other file does.

The cost of getting this wrong isn't hypothetical

A recording uploaded to the wrong vendor's servers can't be un-uploaded after the fact — deleting an account afterward removes future access, not the fact that the audio was transmitted and processed there once already. Choosing a tool that never uploads in the first place avoids needing to trust a deletion request to undo something that already happened, which is a meaningfully different guarantee than "we'll delete it if you ask."

Nothing to turn on, nothing to remember

There's no setting that enables this behaviour, and so no setting that could get switched off by accident during an update or a reinstall — local transcription isn't a preference sitting alongside other preferences, it's simply how the app produces a transcript at all. That's a meaningfully different guarantee from a toggle labelled "process locally when possible," which still depends on the toggle having been found, understood and left alone.

The short version, stated plainly

Recording happens on the Mac. Transcription happens on the Mac, while the call runs. The summary happens on the Mac, once it ends. At no point in that sequence does the audio need to leave the machine for any of it to work, which is the entire claim this page has been walking through one step at a time.

What it costs, what it runs on

Transcribing without uploading isn't a separate tier or an add-on — it's how Coii AudioNotes works by default, for $19 paid once, on macOS 13 Ventura or later, Apple Silicon or Intel. The 30-day trial needs no card and no account, the same as the finished product: nothing about trying it first requires handing anything over before deciding it's worth keeping.