Short answer: Sublime Text has no built-in dictation, so you use a system-wide Mac dictation tool that types at the cursor. Click into the buffer first, hold your hotkey, speak, and release. Dictate prose (comments, docstrings, READMEs, commit messages) and keep typing the syntax.
Sublime Text is still one of the fastest editors on the Mac. It opens instantly, it handles enormous files without complaint, and it stays out of your way. What it does not have, and has never had, is any concept of voice input. There is no dictation command in the menu bar, no Package Control plugin that turns speech into text at the cursor in a way most people would trust, and no setting to look for.
That turns out not to matter much, because the fix does not live inside Sublime at all. A system-wide dictation tool on macOS inserts text wherever your cursor happens to be, and Sublime is just another text field as far as the operating system is concerned. Once that is set up, everything else in this guide is about the specific ways Sublime behaves differently from a browser or a word processor, and how to avoid the three or four first-run failures that make people give up in the first ten minutes.
What dictation is actually good for in a code editor
The single biggest reason people bounce off voice input in an editor is that they try it on the wrong thing. They open a Python file, try to speak a line of code, watch it come out as a mangled sentence with the word "underscore" spelled out, and conclude the whole idea is nonsense.
They are right about that specific test and wrong about the conclusion. Code is not prose. It is dense punctuation, invented identifiers, and structure that your fingers already produce faster than your mouth can describe it. Nobody who dictates productively in an editor is dictating code.
What they are dictating is the English that surrounds the code, and there is far more of it than most developers admit:
- Comments that explain why, not what. The one-line comment above a strange branch. The block at the top of a file explaining the constraint that made the design ugly.
- Docstrings and function documentation. Parameter descriptions, return semantics, the caveat about what happens on an empty input.
- READMEs, CHANGELOGs, and design notes. Sublime is a genuinely good Markdown editor, and these files are pure prose.
- Commit message bodies. The subject line is short. The body, which is where the actual value is, is usually left blank because typing it costs a minute you did not budget.
- Issue and pull request text drafted in a scratch buffer before it gets pasted into a browser.
Look honestly at a week of your work and a large fraction of the characters you type are English sentences. An average adult types somewhere around 40 words per minute in sustained prose. Speech runs at 130 to 150 words per minute without any training at all. That gap is why the comment above the weird branch says // fix this later instead of the two sentences that would have saved the next person an hour. The comment is not missing because you did not know what to write. It is missing because writing it cost twenty seconds in the middle of a thought.
Setting it up
The setup is short because nothing goes into Sublime.
- Install Voice Keyboard Pro on your Mac. It lives in the menu bar.
- Grant Accessibility and Microphone permission when macOS asks. Accessibility is what allows text to be inserted at the cursor in any application, including Sublime.
- Pick a hotkey. Read the next section before you pick it.
- Open Sublime, click into an actual buffer so the caret is blinking, hold the hotkey, say a sentence, release.
The text appears where the caret is. No Package Control package, no .sublime-settings edit, no plugin that breaks the next time Sublime updates. If you work on machines where you cannot install editor packages, or you keep your Sublime configuration synced across several machines and do not want to add anything to it, this matters more than it sounds.
Choose your hotkey carefully
Sublime is more forgiving than a modal editor here, because almost every Sublime command is bound to a modifier combination rather than a bare letter. You are not going to hit the Vim problem where a stray keystroke in normal mode reformats the file.
Even so, Sublime binds a lot. Command with nearly every letter is taken, Command-Shift adds another full alphabet, and Control-Shift is used as well. The safest choices are a function key such as F13 through F19, or a single modifier held on its own like right Option. Pick something your hands can reach without leaving the home position, then test it in a scratch buffer before you rely on it.
If you have any of Sublime's Vim emulation enabled, whether that is the bundled Vintage package or a third-party equivalent, treat this as a hard warning. In normal mode your dictated sentence is not text, it is a sequence of commands, and a paragraph of English will delete lines, enter insert mode partway through, jump the caret and generally leave the buffer in a state you will need undo to escape. If you use Vim bindings, press i first, every time, and confirm you are in insert mode before you speak. Undo is your friend if you forget.
Four Sublime behaviours that will surprise you
Dictated text arrives as keystrokes, which means Sublime's editing features respond to it exactly as they respond to you. Four of those features are worth knowing about before they catch you.
1. Multiple cursors
This is the one that startles people. Sublime's multiple cursors are its signature feature, and if you have several carets active when you start speaking, your sentence is inserted at every single one of them. If you just finished a Command-D selection sweep across twelve occurrences of a variable, you now have twelve copies of your comment scattered through the file.
It is not destructive and undo handles it cleanly, but the habit worth building is simple: press Escape to collapse to a single cursor before you dictate. Escape costs nothing and it takes about two days to become automatic.
2. Auto-pairing of brackets and quotes
Sublime automatically inserts the closing half of brackets and quotes. If your dictation produces a quotation mark or a parenthesis, Sublime helpfully adds its partner, and you end up with doubled characters that you have to go back and clean up.
In practice this bites hardest when you dictate a sentence containing a quoted phrase or a parenthetical aside inside a comment. Two ways to handle it: avoid speaking punctuation that auto-pairs and add it by hand afterwards, or turn off auto_match_enabled for the syntaxes where you do most of your prose, such as Markdown and plain text. Sublime supports syntax-specific settings, so you can leave the behaviour on for your code files and off for your documentation.
3. The autocomplete popup
Sublime's completion popup appears as you type words, and it commits on Tab and, depending on your settings, on Enter. Dictation that includes a line break can therefore commit a completion you never asked for, replacing the word you just spoke with a symbol from elsewhere in the file. The result is a comment that reads almost right until you notice one word has been swapped for a function name.
The clean fix is to make Tab the only key that commits a completion, so a dictated newline never triggers one. If you write a lot of Markdown in Sublime, disabling autocomplete for that syntax entirely is even simpler. Either way, proofread the first few dictated blocks until you know how your configuration behaves.
4. Auto-indent inside comment blocks
When you dictate a multi-line paragraph into a block comment, Sublime continues the comment leader and the indentation on each new line. Usually that is what you want. Occasionally the indentation compounds in a way that looks wrong, particularly inside nested structures.
The easy workaround is to dictate the paragraph as one continuous run without speaking line breaks, then reflow it afterwards. Sublime handles the wrapping better than the dictation does, and you get a cleaner result in less time.
Where to draw the line: speak the sentences, type the syntax
This is the rule that decides whether voice input in an editor feels like a superpower or a chore. Some text belongs to your mouth and some belongs to your fingers, and the boundary is sharper than people expect.
Speak: anything that is a sentence. Explanations, rationale, parameter descriptions, README sections, commit bodies, TODO notes with actual content in them, notes to your future self about why the workaround exists.
Type:
- Code itself. Braces, semicolons, operators and closures are faster and more accurate from the keyboard, every time.
- Identifiers. Camel case, snake case and kebab case do not survive the trip through speech reliably, and correcting them costs more than typing them did.
- File paths and import statements. Slashes, dots and extensions are punctuation-heavy and error-prone.
- Regular expressions. Obviously.
- Numbers that matter. This is the sneaky one. A wrong digit in a version number, a port, a timeout or a threshold looks completely correct on the page. Prose errors announce themselves; numeric errors do not. Type the numbers.
Once you have internalised that split, the workflow settles into something natural: you type the structure, then speak the paragraph that explains it. Most people find the ratio lands around two-thirds typing, one-third speaking, and the third that gets spoken is the third that used to not get written at all.
Five surfaces in Sublime worth dictating
The comment above the confusing code
Start here. It is the highest-value, least-written text in any codebase. When you have just wrestled something into working, the context is fresh and complete in your head and it will be gone in a week. Collapse to a single cursor, open a comment, and say three sentences: what this does, why it is done this way, and what will break if someone changes it. Twenty seconds of speech, and the next person who opens the file gets the whole story instead of a shrug.
Docstrings and API documentation
Function documentation is formulaic prose, which makes it ideal for speech. Type the docstring delimiters and the parameter names, then speak the descriptions. The structure comes from your fingers, the English comes from your mouth, and the whole thing takes a fraction of the time. This is the same division of labour that works in VS Code and Zed, so if you split your week across editors the habit transfers cleanly.
READMEs and design docs
Sublime with a Markdown syntax is a fast, distraction-free writing environment, and READMEs are the documents most likely to be thin because writing them felt like a tax. A README section that would have taken you fifteen minutes to type takes four or five to speak and edit. The install steps, the "why this exists" paragraph, the troubleshooting notes at the bottom that everyone skips writing: these are all pure prose.
Commit message bodies
Many people set Sublime as their Git editor, which means the commit buffer opens right there. The subject line stays typed, because it is short and conventions matter. The body is where dictation pays. Explaining what changed and why in three sentences turns a commit log from a list of shrugs into something you can actually read six months later during a bisect. If you prefer to stay in the shell, the same approach works for writing commit messages in the terminal.
The scratch buffer that becomes an issue
Sublime's unsaved scratch buffers are perfect drafting space. Speak the bug report, the pull request description or the message to a colleague at full speed, clean it up, then paste it into the browser. Drafting in an editor you control beats drafting in a web textarea that might lose your work, and dictation makes the first draft nearly free.
Making it accurate: the identifier problem
Every codebase has its own vocabulary. Internal service names, library names, product names, an abbreviation that only means something to your team. General-purpose transcription has never seen any of them, so it produces the closest ordinary English word instead, and you spend your editing pass fixing the same four words over and over.
Smart Vocabulary in Voice Keyboard Pro is the fix. It is a personal dictionary with replacement rules, so you tell it once how you say a term and what it should write, and the correction happens before the text reaches your buffer instead of after. Front-load it with the twenty or thirty names you say most often in your project and the correction pass mostly disappears. This is the same tool that solves the problem for acronyms and abbreviations, which break for exactly the same reason.
A related habit that costs nothing: dictate the sentence, then go back and fix the one identifier. Stopping mid-sentence to correct a word destroys the flow that made speaking fast in the first place. Speak the whole thought, then edit. Sublime's multiple cursors and Command-D make replacing a repeated wrong word almost instant, which is a nice irony given that multiple cursors were the hazard three sections ago.
Voice Edit and the second pass
Dictated first drafts are looser than typed ones. That is a feature, because the loose draft exists and the tight one that never got written does not, but it does mean editing is part of the workflow rather than optional.
Two things make the second pass cheap. Voice Edit lets you speak a change to text you have already written, so you can say what you want fixed rather than navigating to it with the caret. And Sublime's own editing tools were designed for exactly this kind of cleanup: multiple selections, incremental find and replace, and column selection turn a rough paragraph into a tidy one in a few keystrokes.
The mental model that works: voice produces volume, keyboard produces precision. Use each for what it is good at and stop trying to make either one do the whole job.
Capture away from the desk
A fair number of good comments and design decisions arrive when you are nowhere near Sublime. The Voice Keyboard Pro iPhone keyboard has a mic button built in, so you can dictate into any iOS app: a note, a message to yourself, an issue tracker in the browser. Speak the paragraph while it is fresh, then paste it into the file when you are back at the machine. The alternative is trying to reconstruct the thought two days later, which never produces the same explanation.
Troubleshooting
Nothing appears when I speak. Almost always the Accessibility permission. Check System Settings, Privacy and Security, Accessibility, and confirm Voice Keyboard Pro is listed and enabled. If you have just granted it, quit and reopen the app so the new permission takes effect.
Text lands in the wrong place. Sublime needs to be the frontmost window and the caret needs to be in a buffer, not in the command palette, the find bar or the sidebar. Click into the text and confirm the caret is blinking before you hold the hotkey. This is the same rule that applies to dictating at the cursor in any Mac app.
My sentence appeared twelve times. Multiple cursors were active. Undo, press Escape, dictate again.
The hotkey does something in Sublime instead of recording. You picked a combination Sublime has bound. Open your key bindings, search for the combination, and either rebind Sublime's command or pick a different hotkey. A function key is the path of least resistance.
Accuracy is poor. Check which microphone macOS is actually using, since a Bluetooth headset in the wrong mode is a common culprit. Speak at a normal conversational pace rather than slowly and carefully, because unnaturally slow speech tends to hurt rather than help. And add your project's vocabulary to Smart Vocabulary if the same handful of words keeps coming out wrong.
Frequently asked questions
Is there a Sublime Text dictation plugin? Nothing that is widely used or maintained. That is fine, because the system-wide approach is strictly better here: it works in Sublime, in your terminal, in the browser, and in every other app, with one set of settings and nothing to break when Sublime updates.
Does this work in Sublime Merge? Yes. Sublime Merge's commit message field is a text field like any other, and the commit body is one of the best places to use dictation.
Should I dictate code? No. Type the code, speak the English around it. Anyone selling you on dictating raw syntax is describing a different, much larger project involving custom speech grammars, and it is not what this guide is for.
Does it work offline? No, it needs a connection. If you work somewhere without one, macOS has built-in dictation as a fallback, with the accuracy and session-length limits that come with it.
What about Windows or Linux Sublime? Voice Keyboard Pro is macOS and iOS only. This guide is written for the Mac.
What does it cost? There is a free tier with daily limits, which is enough to find out whether the habit sticks. Pro is $4.99 a month or $34.99 a year.
Is my code or my speech stored anywhere? No. Audio and transcript content are not retained on the server. Only operational pings are recorded, which means counts and timings, not what you said or wrote. Given that your comments describe your architecture, this is worth knowing rather than assuming.
The week-one test
Do not try to change how you write code. Change one thing: for one week, every time you are about to leave a comment blank or write // TODO with nothing after it, press the hotkey and say the two sentences instead.
At the end of the week, open a file you worked on and read the comments. The difference is not that you typed less. It is that the explanations exist. The reason most codebases are under-documented is not that developers do not know what to say, it is that saying it in writing costs more than the moment allows. Removing that cost is the entire point.
The comment you did not write is not a discipline problem. It is a typing-speed problem.
Sublime will keep doing what it does best: opening instantly and getting out of the way. Voice Keyboard Pro just fills in the part Sublime was never going to solve, which is that your fingers are slower than your thoughts and always have been.