Custom Vocabulary Transcription: Teach It Your Terms

Author: Hushscript | Published: July 12, 2026 | Last reviewed: July 22, 2026

A general-purpose speech engine has less context for a product codename, a regional surname, or an internal acronym your team uses ten times a meeting. Research calls the technique for steering recognition toward expected terms contextual biasing, and a 2025 W3C Web Speech session described it as a capability shipping in Chrome. Hushscript turns that idea into four vocabulary controls, ranging from a one-off addition for one file to a standing setup you can reuse.

Where custom vocabulary helps most

Three categories cause most of the recognition misses a general-purpose model makes. People’s names are the first, especially spellings that aren’t the most common variant. A model has no way to guess whether the audio said “Nguyen” or a near-homophone unless something tells it the name is in play. Product and brand names are the second: a name like “FlowBridge” gets heard as the two ordinary words it sounds like, not the proper noun a specific company chose. Internal jargon and acronyms are the third: terms that only mean something inside one team or industry, which no general vocabulary was ever going to contain. A clinical practice’s drug and procedure names are the same problem at a larger scale, which medical transcription handles with a dedicated mode alongside these vocabulary tools. An acronym repeated ten times in a meeting either transcribes wrong ten times or right ten times; there’s no partial credit, so fixing it once in a keyterm list or dictionary fixes every occurrence in that file automatically.

For a single file: keyterms and a custom prompt

If you’re transcribing one unusual recording and don’t need a permanent setup, add keyterms directly to that job. Up to 1,000 keyterms (names, brands, acronyms) bias recognition toward the words you actually said, for that file alone. Alongside them, a custom prompt of up to 2,000 characters gives the engine context the audio alone can’t: who’s speaking, what the recording covers, terms specific to the situation. Both disappear after the job; nothing carries over to the next file unless you add it again.

For recurring work: saved dictionaries and prompt presets

If the same names and jargon come up file after file, a one-off list stops being worth retyping. A saved dictionary solves that: import terms in bulk from a CSV or TSV file, organize them into categories, and attach spelling variants to each canonical term so “McAllister” is recognized whether the source audio makes it sound like “MacAlister” or “McAllaster.” Prompt presets work the same way for context, saving the background you’d otherwise retype every time. Mark either a dictionary or a preset as your default, and it’s preselected automatically the next time you transcribe, so a standing setup doesn’t need reselecting on every file.

They combine, they don’t replace each other

A standing dictionary and a one-off addition aren’t a choice between two options; they apply to the same job together. Keep a default dictionary of your team’s product names and a default prompt describing what your recordings usually are, then add a one-off keyterm for a guest’s name that’s only relevant to this week’s file. The standing setup covers the recurring vocabulary; the one-off addition covers what’s specific to this recording. Neither one has to account for what the other already handles.

What it doesn’t touch

Custom vocabulary in any of its four forms shapes what the engine hears while it is transcribing, and it does not configure the later Insights job. Insights run against the transcript that results. Getting the vocabulary right earlier can therefore improve the source text that Insights reads, without changing what Insights generates.

A worked example

A weekly podcast interviews a different guest each episode but always covers the same three product lines by name. The host builds a saved dictionary once, imported from a spreadsheet of product names and the team’s own names, spelled the way the show actually says them, and marks it as the default. Every week’s episode benefits automatically. For the guest that week, a name the standing dictionary has no reason to know, the host adds one keyterm before uploading, specific to that file. The standing dictionary and the one-off keyterm both apply to the same transcript, and neither required touching the other.

Where to set it up

Vocabulary options sit alongside the other per-file settings on audio to text, whether you’re adding a one-off keyterm to a single upload or managing a saved dictionary for recurring work. They work the same way regardless of which of the roughly 99 languages Hushscript auto-detects in the recording, and the languages page has the full list, along with which ones get top-tier accuracy. For more on getting the transcript itself right before you worry about vocabulary, see how to transcribe a podcast for the recurring-guest workflow this example follows.