Best dictation APIs for developers in 2026

Here's what a user actually says when they dictate a note: "um so I, I think we should uh — we should probably ship the, the retry logic first."

Here's what they meant to write: "I think we should ship the retry logic first."

Every dictation feature lives or dies in that gap. And most of the APIs developers reach for to close it are speech-to-text APIs, which are built to do the opposite — capture every word exactly as spoken, filler and false starts included. That's correct behavior for a transcript. It's the wrong output for a text field.

Dictation stopped being an operating-system feature somewhere around 2025 and became a feature of everything: notes apps, clinical tools, coding agents, writing tools, booking flows. If you've been handed "add dictation" and a week to scope it, this is the guide to what your options actually return, what to evaluate them on, and which one fits the thing you're building.

What a dictation API is, and how it's different from a speech-to-text API

A dictation API returns finished, paste-ready text from spoken audio. A speech-to-text API returns a verbatim transcript. The difference isn't accuracy — it's what the output is for.

Transcription models are trained to be faithful. If you said "um," a good transcription model transcribes "um," because a transcript that silently edits the speaker is a broken transcript. That fidelity is the whole point when you're building search over recorded calls or captions for a video.

Dictation inverts the requirement. Nobody wants to paste "um so I, I think we should uh" into a chart note, a Jira ticket, or a terminal. The user's intent was a clean sentence, and anything short of that leaves the cleanup work on your side of the API — which in practice means a second call to a language model, a prompt you now maintain, and latency you now own.

So a dictation API is a speech-to-text API plus a defined output contract: disfluencies removed, punctuation and capitalization applied, and — on the better ones — an instruction surface that lets you shape the result per request. We wrote up the mechanics of that cleanup step in more detail in inside dictation cleanup.

The confusing part of shopping for one in 2026 is that almost nothing marketed under the word "dictation" is this. Some of it is a punctuation flag. Some of it is a consumer app. Some of it is a batch analysis pipeline. Knowing which is which is most of the evaluation.

Six things to evaluate (and one that doesn't matter)

1. Time to finished text, not time to first token. Dictation is a UI-blocking interaction. Your user has stopped talking and is now staring at the cursor. There's no background job here and no spinner you can get away with — if the text isn't there when they look up, the feature feels broken no matter how good it eventually is. Streaming APIs advertise time to first partial, which is the wrong number. Measure the wall clock from "user releases the hotkey" to "final text is in the field."

2. Where the cleanup happens. If the API returns verbatim text, the cleanup is your problem, and that means a second sequential inference call. Latency compounds: two round trips, two failure modes, two rate limits, two bills. If the cleanup happens inside the request, ask where — a provider routing your audio through a third-party LLM is a different security review than one running post-processing on infrastructure it owns.

‍3. Whether you can steer the output. Fixed cleanup handles the common case. What you'll want by month two is per-request control, because your UI probably has modes: a clinician picking "SOAP note," a writer picking "keep my voice," a developer dictating a structured prompt into a coding agent. If the instruction is a request parameter, your UI can drive it. If it's an account-level setting, it can't.

4. Accuracy on the words that matter. Not overall word error rate — accuracy on drug names, proper nouns, package names, version strings, and numeric IDs. These are the words a user notices, and they're the words a cleanup pass cannot save (more on that below). Look for contextual prompting or custom vocabulary, and check whether those parameters conflict with anything else you need.

5. Language coverage, and which layer it applies to. Ask the question twice: how many languages does transcription support, and what does the cleanup or formatting layer support? These are frequently different numbers, and vendors rarely separate them. If a meaningful share of your users dictate in a language other than English, get both answers in writing.

6. Request shape and limits. Clip-length ceilings, audio formats, whether there's an SDK or just an HTTP endpoint, what happens on a timeout. Dictation clips are short and bursty — a different traffic profile than batch transcription, and some APIs are priced and rate-limited for the latter.

The one that doesn't matter: streaming partials. Watching words appear as you speak is a nice demo that buys a dictation feature almost nothing — the user isn't reading the partials, they're waiting for the final text. Progressive text matters for live captions and voice agents. For dictation, one round trip beats two.

If you want the deeper version of the accuracy piece, how to evaluate speech recognition models covers benchmark design, and our notes on comparing accuracy across vendors explain why published numbers are hard to compare and why you should test on your own audio.

The options, compared

Six of the seven options below are speech-to-text products that developers use for dictation. That's not a knock — several are excellent at what they do. It's the thing to understand before you pick one, because it tells you how much of the work is still yours.

AssemblyAI Dictation API

Purpose-built for dictation, and the reason we wrote this post. The Dictation API takes one POST with an audio file and returns both versions of the text in the same object: text holds the verbatim transcript, llm_response holds the finished version. The rewrite is on by default — send audio with no config at all and you get filler sounds, false starts, and stammered repeats removed, with every kept word, its spelling, and its punctuation left exactly as spoken. Set config.llm.instruction to do more than that.

It's built on Universal-3.5 Pro, the same flagship model behind our async and streaming APIs, not a smaller variant — which matters for reason four above. Transcription covers 19 languages. Typical short clips respond in under one second, and every response reports its own request_time_ms, so you can measure that claim rather than trust it. $0.62/hr all-in, one line item covering transcription and post-processing. Clips cap at 120 seconds, and there's no SDK — it's one HTTP call.

Deepgram

Worth clearing up, because the naming collides. Deepgram ships a dictation parameter, but it does something specific and narrow: it converts seven spoken commands — "period," "comma," "colon," "question mark," "exclamation mark," "new line," "new paragraph" — into the corresponding marks. It requires punctuate=true alongside it and is English-only.

That's a genuinely useful feature, and it is not a dictation API in the sense this post is about: you still get a verbatim transcript, and the disfluencies are still yours to remove. If spoken punctuation control is the thing you need, this is the cleanest implementation of it.

Gladia Audio-to-LLM

The closest structural comparison to a dictation API. Audio-to-LLM runs transcription, diarization, and LLM analysis in a single POST, and you can pick from a large catalog of third-party models routed through OpenRouter by changing a config value.

The catch for dictation is the shape, not the quality: it's async and batch, with results returned by webhook, and token costs sit on top of async transcription starting around $0.50/hr. For turning a recorded meeting into structured output, that's a sensible design. For a user who just released a hotkey and is watching a cursor, a webhook is the wrong delivery mechanism.

ElevenLabs Scribe v2 Realtime

Fast, accurate streaming speech-to-text — ElevenLabs advertises around 150ms latency across 90 languages at $0.28/hr. There's no cleanup or formatting layer, so you bring your own, which puts you back in the two-call pipeline.

It's on this list because any serious evaluation will already have it on the shortlist, and it's a strong choice if what you need is a verbatim stream with wide language coverage.

OpenAI transcription

The default first attempt for most teams, and the one that most often produces the "why is this so messy" moment that leads to a post like this one. File transcription accepts uploads up to 25 MB, the realtime path is a separate product, and cleanup means a second call to a second model with a prompt you maintain. Fine for a prototype — but the pipeline you end up with is the pipeline this article is about.

Google Cloud Speech-to-Text and Azure Speech

Grouped together because the reasoning is the same: very broad language coverage (Google advertises 125+), deep integration with the rest of the cloud, and no dictation-specific output layer. If your company already has a committed spend agreement and a completed security review with one of them, that advantage is real and probably outweighs everything else on this list.

Web Speech API

Free, no infrastructure, no API key, runs in the browser. Per MDN, SpeechRecognition is not Baseline because it doesn't work in some of the most widely-used browsers, and quality varies by browser in practice. For a weekend prototype this is the honest recommendation. For a product feature you intend to support, the inconsistency will find you.

What building it yourself actually costs

The build-versus-buy math on dictation is more interesting than it looks, because the dollar difference is small and it's not the point.

Wire a streaming STT vendor to a fast language model and you'll land in roughly the same per-hour range as an integrated dictation API. What you also get is a second sequential inference call in a latency-critical path, a prompt to maintain as your product's output requirements change, two vendors' rate limits to plan around, two failure modes to handle, and two security reviews to get through. Then someone asks for Spanish, or a clinician asks for SOAP notes, and the prompt becomes a small internal product with an owner.

The teams who've done this well mostly agree on where the effort actually went: not the plumbing, the tuning. Holding output quality steady across accents, hard terms, and languages while keeping the whole round trip under a second is the work.

It's also worth being clear about what users notice when you get the latency right. Granola, which builds a bot-free AI notetaker on our speech models, put it this way:

"The speed difference is immediately noticeable — our users see their conversations transcribed almost instantaneously. It feels so much more responsive than what we were using before."

— Jonathan Kim, Software Engineer, Granola

If you do build it yourself, LLM Gateway is a reasonable way to keep the rewrite pass on one bill and one set of logs, and dictation features documents the two request patterns teams are converging on — one clip per utterance, or a chunk per pause.

The failure mode nobody budgets for

Cleanup polishes text. It does not correct it.

Hand a language model a transcript that misheard a drug name, and it returns a confident, well-punctuated, correctly formatted wrong drug name. That reads worse than a messy right answer, because fluent text reads as authoritative. A user who sees "um, so, metaprolol, uh, 25 milligrams" knows to look twice. A user who sees "Metoprolol 25 mg BID" does not.

This is why the model underneath matters more in dictation than in transcription. In transcription, a reviewer usually sees the raw output and catches the error. In dictation, the raw output is discarded and the polished version goes straight into a document.

The practical version of this: use the parameters that steer recognition, not just the ones that steer formatting. Our docs draw the line cleanly — prompt tells the model what it's about to hear, the setting and the vocabulary; llm.instruction tells the model what to do with the transcript after it's written down. Loading your product's proper nouns, your users' jargon, and your domain's terminology into the first one is what keeps the second one from confidently formatting a mistake. Our published benchmarks are the place to compare model accuracy before you get to formatting.

One related note for anyone building in healthcare: AssemblyAI is considered a business associate under HIPAA, and we offer a standard Business Associate Addendum (BAA) that is required under HIPAA for customers processing protected health information. Diarization, PII redaction, and Speech Understanding features aren't supported on the dictation endpoint — those live on the async API.

Your first call, end to end

No SDK. Two form fields.

curl -X POST https://dictation.assemblyai.com/transcribe \
  -H "Authorization: <YOUR_API_KEY>" \
  -F "audio=@utterance.wav"

That's the whole default path. The response carries both versions of the text plus its own timing:

{
  "text": "um so I, I think we should uh — we should probably ship the, the retry logic first",
  "llm_response": "I think we should ship the retry logic first.",
  "request_time_ms": 812,
  "sync_time_ms": 604,
  "audio_duration_ms": 6120,
  "confidence": 0.97
}

‍

request_time_ms is total server-side processing; sync_time_ms is the transcription portion. The difference is what the rewrite cost you.

To shape the output instead of just cleaning it, add the config part:

curl -X POST https://dictation.assemblyai.com/transcribe \
  -H "Authorization: <YOUR_API_KEY>" \
  -F "audio=@utterance.wav" \
  -F 'config={"llm": {"instruction": "Remove filler words and rewrite as a concise
  clinical chart note."}}'

Same audio, different instruction, different finished text. Send {"llm": null} to turn the rewrite off entirely and get verbatim output. The rewrite has a five-second internal deadline — if it's exceeded you still get a 200 with the verbatim transcript and llm_error: "timeout", because returning something fast beats returning something perfect slowly.

If you'd rather feel it before you read docs: Blurt is a free, open-source macOS dictation app that runs on your own API key. Hold a hotkey, speak, and finished text lands in whatever app you're in — one Dictation API call per utterance. It's a demo vehicle, not a product we sell, and it's the quickest way to understand what "finished text" means in practice.

Which one to pick

You're shipping dictation as a product feature. Use a dictation API. The reason isn't the per-hour price, it's that output shaping and sub-second round trips are the two things you'd otherwise spend a quarter building and then maintaining.

You need a verbatim stream with very wide language coverage. ElevenLabs Scribe v2 Realtime or one of the hyperscalers. Add your own cleanup pass and accept the second call.

You're already deep in Google Cloud or Azure. Start there. A completed security review and an existing spend agreement are worth more than a modest technical edge, and you can always move the cleanup layer later.

You're prototyping this weekend. Web Speech API. It costs nothing, ships in an afternoon, and will tell you quickly whether the feature is worth building properly.

You're turning recorded audio into structured output rather than dictating live. That's a different job, and an async pipeline like Gladia's Audio-to-LLM — or our own async API — is the right shape for it.

The interesting part is what comes next

This category exists because dictation quietly became a default input method rather than an accessibility feature, and the tools to build it hadn't caught up. That gap is closing fast, and the next round of differentiation probably isn't accuracy or latency — both are getting good enough to stop being the deciding factor.

It's control. Which model does the rewrite, how much of your product's context reaches the recognition step, whether the instruction can carry a user's own style. Teams shipping dictation are already asking for those things. So if you're evaluating now, weight the instruction surface more heavily than the benchmark table: the benchmark gap will narrow, and the control surface is what you'll be living with.

Frequently asked questions

What is a dictation API and how is it different from a speech-to-text API?

A dictation API returns finished, paste-ready text from spoken audio, while a speech-to-text API returns a verbatim transcript of exactly what was said. Speech-to-text is trained to be faithful, so it keeps filler words, false starts, and self-corrections — correct for a transcript, wrong for a text field. A dictation API adds a defined output contract: disfluencies removed, punctuation applied, and on the better ones, an instruction you can set per request to shape the result.

How do I choose a dictation API for my product?

Evaluate on time to finished text rather than time to first token, since dictation is a UI-blocking interaction where the user is waiting on the cursor. Then check where the cleanup happens, whether you can steer the output per request, accuracy on the specific terms your users say, language coverage for both the transcription and formatting layers, and clip-length limits. Streaming partials matter far less than teams expect.

Is it worth paying for a dictation API, or should I combine a transcription API with GPT myself?

The dollar difference between the two is small; the difference in latency and maintenance is not. Doing it yourself adds a second sequential inference call in a latency-critical path, plus a cleanup prompt you own, two sets of rate limits, and two failure modes. Teams who have built it report the cost was in tuning output quality across accents, hard terms, and languages — not in the initial plumbing.

How do I add a dictation feature to my app using an API?

Capture a short audio clip on a hotkey or press-and-hold, send it to a dictation endpoint, and insert the returned text into the focused field. With the AssemblyAI Dictation API that's a single POST with an audio file — no SDK — and the response contains both the verbatim transcript and the finished text, so you can show either one. Most teams use one of two patterns: one clip per utterance, or a chunk per pause.

How do I improve dictation accuracy for custom vocabulary and industry jargon?

Steer recognition, not formatting. Parameters like prompt, word_boost, and conversation_context prime the model with the setting and vocabulary it's about to hear, which is what actually gets a drug name or a package name right. A cleanup pass cannot fix a misheard word — it will return a confidently formatted wrong one — so loading your domain terms into the recognition step is the fix.

Does AssemblyAI's Dictation API support languages other than English?

Transcription covers 19 languages, set via language_codes, which defaults to English. Note that language_codes is ignored when a custom prompt is set, so don't configure both on the same request. Confirm coverage for the formatting layer separately in the docs before shipping a non-English dictation experience.

‍