Voice message transcription on Mac in 2026: which apps actually work, per platform

The platform-by-platform reality

Most guides on this topic pick one app, usually WhatsApp, and pretend the answer generalises. It does not. Each messaging app has made a different bet on whether to ship transcription, where to run it, and how to gate it. The table below captures the state I verified on 2026-05-12 by reading each vendor's own docs and product pages. The Mac column is the one that matters for the question this page answers, and it is the one most other guides skip.

The universal fallback: share-extension apps

For the three platforms with nothing built-in on Mac (iMessage, Discord, Signal), and for the two that only render mobile-initiated results (WhatsApp, Telegram), the practical workaround is a share-extension app on the Mac App Store. The two most commonly installed are Transcriptor and Voicepop. The workflow is identical for either one.

The other half of the workflow nobody writes about

The pages that rank for this question all focus on the receive side. They assume you are the person reading a voice message someone else sent. That is one half of the workflow. The other half is the reply. A surprising number of users record a voice reply specifically because typing the response would be slower, especially when the message is peppered with product names, URLs, and short technical strings.

When you receive a voice note transcribed as “the empty pee server crashed, ping matthew at fazm dot ai”, you parse it in your head and move on. When you DICTATE that same sentence into a Mac dictation tool and SEND it back, your recipient sees word salad. So the inverse problem has a different shape: the transcript has to be producible directly, with product nouns and URL forms intact, no mental cleanup step.

Most dictation tools do not handle this. Apple's built-in dictation has no custom vocabulary API. WhisperKit (the on-device Whisper port that ships in several Mac dictation apps) accepts an initial-prompt hint but its effect on rare proper nouns is weak. The hosted vendors (Deepgram Nova-3, AssemblyAI, OpenAI Whisper API) all offer a vocabulary parameter, but the dictation app on top has to actually wire it in and ship a sensible seed list.

What the pipeline actually has to do

Outbound dictation that produces sendable transcripts has three moving parts. The mic capture layer feeds 16-bit PCM samples into a streaming speech model. The model has been pre-biased with a curated vocabulary so it knows that “MCP” is a real word in your dialect. A find-and-replace pass after the model rewrites known spoken-form patterns into their text form before any of it lands in a UI.

Fazm's open-source code shows what each leg of this looks like in production. The audio capture front end at Desktop/Sources/AudioCaptureService.swift targets 16000 Hz mono Float32 PCM (see targetSampleRate near line 55). The streaming layer at Desktop/Sources/TranscriptionService.swift uses Deepgram Nova-3 over a WebSocket at wss://api.deepgram.com/v1/listen (line 276) with smart_format, punctuate, interim_results, and endpointing=300 (lines 280 through 288). The vocabulary and the replacement rules attach to the same request as repeated query items:

// TranscriptionService.swift, around line 295
for term in vocabulary {
    queryItems.append(URLQueryItem(name: "keyterm", value: term))
}

if language == "multi" || language.hasPrefix("en") {
    for rule in Self.defaultReplacements {
        queryItems.append(URLQueryItem(name: "replace", value: "\(rule.find):\(rule.replace)"))
    }
}

The 18 spoken-form replacements Fazm ships by default

These are the “dot com” and “at sign” rules that get attached to every English or multi-language transcription request. The table lives as the static let defaultReplacements: [(find: String, replace: String)] property on TranscriptionService, lines 16 through 31. They run server-side at Deepgram, so the segments coming back over the WebSocket already have the substitutions applied. The same rules generalise to any dictation pipeline you build on Nova-3.

Two notes on this set. The TLDs are not exhaustive, “dot ru” or “dot uk” are missing because the seed list targets the TLDs that show up most often in tech speech. The file extensions (.json, .js, .ts, .py, .swift, .css, .html) only matter if you actually dictate file names; if you do not, they are harmless but unused.

The 18 product nouns in the seed vocabulary

Every name on this list is a token that base Nova-3 mis-hears with high probability and that has near-zero collision with common English. The seed list is small on purpose. Deepgram's docs note the limit is 500 entries per request, but a comment in the Swift source flags that effectiveness drops past ~30 terms because the bias starts colliding with itself. Users add their own (their colleagues' names, their internal tools, their CRM stages) and the user list goes first; removing a system term persists into disabledSystemVocabulary so an upgrade does not silently restore it.

The list lives in Desktop/Sources/DeletedTypeStubs.swift near line 657 in github.com/mediar-ai/fazm. Pull it as a starting seed, prune the half that are not in your dialect, add 5 to 10 of your own, and you are at the ~30-term sweet spot.

So which side of this matters for you

If the workflow you are trying to fix is “a colleague sends me a 90-second voice note and I want to read it”, install a share-extension app and call it done. The platform-by-platform breakdown above shows you where to wire it in for each app you use. You do not need a fancier tool than that.

If the workflow you are trying to fix is “I keep sending voice replies because typing is too slow but the transcripts I hand off look bad”, the share-extension model is not the right shape. You need a dictation pipeline with custom vocabulary and a replacement table, running close enough to the keyboard that the tuned transcript becomes the thing you actually send. That is the gap a voice-first agent like Fazm sits in, with the caveat that the agent layer is doing more than dictation, it also routes the transcript to whichever app you have focused (Messages, Slack, the browser, etc.) via macOS accessibility APIs. If all you wanted was a tuned dictation surface and not a full agent, the same Deepgram parameters above will give you that on their own, you just have to build the surrounding app.

The honest summary, then: on the receive side this is a solved problem with off-the-shelf apps. On the send side it is still mostly hand-rolled, and the work is in the vocabulary seed list and the replacement table, not the speech model.