Short answer: To dictate in GitHub, install Voice Keyboard Pro on your Mac or iPhone. On Mac, hold your hotkey and speak into any GitHub text box on the web; on iPhone, tap the mic on the Voice Keyboard Pro keyboard inside the GitHub app or Safari. Your words appear as text at the cursor in seconds.
GitHub is where a surprising amount of a developer's writing actually happens. Not the code, the prose around it: the issue that explains a bug, the pull request description that justifies a change, the review comment that asks a teammate to reconsider an approach, the discussion thread that decides an architecture. Good software teams live or die by the quality of that writing, and yet most of it gets typed out in a rush between other tasks, so it comes out terse, half-explained, or skipped entirely.
Speaking is faster than typing, and for many people it is also easier to think out loud than to compose in text. The average adult types around 40 words per minute, while comfortable speech runs 130 to 150 words per minute. When you can talk through a bug report at conversational speed, you tend to include the context you would otherwise leave out. This guide covers how to dictate directly into GitHub on both Mac and iPhone, how to handle markdown and technical vocabulary by voice, and how to make your issues and reviews genuinely clearer in the process.
Why dictate in GitHub at all?
There is a specific kind of friction to writing on GitHub. You have the fix clear in your head, the reproduction steps obvious to you, the reasoning behind the design decision fully formed. Then you open the issue box and stare at it, because turning all of that into typed paragraphs is slow and a little tedious. The result is the classic one-line issue: "login broken, pls fix." Everyone has written one. Nobody enjoys receiving one.
Dictation removes that friction. Speaking a bug report takes roughly the time it takes to describe the bug to a colleague at your desk, because it is the same act. You narrate what you did, what you expected, and what happened instead, and it lands as text. A pull request description that would have been three grudging sentences becomes three clear paragraphs, because the marginal cost of an extra sentence is a few more seconds of talking rather than another line of typing.
This matters most for the parts of GitHub that are pure writing:
- Issue descriptions: reproduction steps, expected versus actual behavior, environment details, and links.
- Pull request write-ups: what changed, why, what to test, and any follow-up work you are deferring.
- Code review comments: the difference between "nit" and a two-sentence explanation of why a change would help.
- Discussions and RFCs: longer-form proposals where the argument matters more than the code.
- Wiki pages and READMEs: onboarding docs and setup guides that never get written because typing them is a chore.
- Commit messages: the body of a good commit, dictated in the GitHub web editor or your terminal.
Dictating in GitHub on Mac
GitHub on the desktop is a website, which is the easiest case for voice input. Voice Keyboard Pro for Mac lives in your menu bar and types at the cursor system-wide, so it works in any browser text field the same way it works in a native app. There is no GitHub extension to install and nothing to configure per site.
One-time setup
- Download Voice Keyboard Pro for Mac from voicekeyboardpro.com and drag it to your Applications folder.
- Open it once and grant microphone and accessibility permissions when macOS asks. Accessibility is what lets the app place text at your cursor in the browser.
- Pick a hotkey you can hold comfortably. Many developers use a function key or a spare modifier so it never collides with editor shortcuts.
Dictating into GitHub
- Open the issue, pull request, or comment box in your browser and click into it so the cursor is blinking.
- Hold your hotkey, speak the sentence or paragraph, then release.
- The text appears in the field within about a second. Keep holding across multiple sentences, or release and re-press for each thought. Whatever rhythm feels natural.
Because the app is system-wide, the same hotkey dictates into your code editor, your terminal, Slack, and your email. You are not learning a GitHub-specific tool, you are learning one dictation habit that follows you everywhere. If you also work across project trackers, the same approach covers dictating in Jira and dictating in Linear without any change to your workflow.
Dictating in GitHub on iPhone
On the phone, GitHub writing is even more painful, because thumb-typing a detailed bug report on a small screen is nobody's idea of a good time. This is exactly where a voice keyboard shines. Voice Keyboard Pro installs as a custom iOS keyboard with a built-in mic button, so it works inside the GitHub mobile app, inside Safari, and in any other app you use to reach GitHub.
One-time setup
- Install Voice Keyboard Pro from the App Store.
- Open Settings → General → Keyboard → Keyboards → Add New Keyboard and add Voice Keyboard Pro.
- Tap it in the list and enable Allow Full Access. This is what lets the keyboard send audio for transcription and return your text. If you want the reasoning behind that toggle, see our guide on enabling Full Access safely.
Dictating into GitHub
- Open the GitHub app and tap into an issue comment, a PR review, or a new issue body.
- Switch to the Voice Keyboard Pro keyboard using the globe key.
- Tap the mic button, speak, and watch your words appear. Tap again to stop.
The keyboard does not care which app you are in, so the same mic button dictates a GitHub review on your commute and a text message five minutes later. That is the whole point of a keyboard-level tool rather than an app-specific one.
Handling markdown by voice
GitHub runs on markdown, and the natural question is whether you can dictate formatting as well as prose. The honest answer is that dictation is best at the words, and you add the structural markup with a light touch. In practice this is faster than it sounds, because the words are the slow part and the symbols are the fast part.
A workflow that holds up well:
- Dictate the prose first, format second. Speak the whole comment or issue body as plain sentences, then go back and add headings, bullets, and code fences with a couple of keystrokes. You spend your voice on the 90% that is language and your fingers on the 10% that is punctuation.
- Speak your punctuation where it helps. Saying "comma" and "period" and "new line" as you talk keeps sentences clean so you are not re-reading a wall of text afterward.
- Use fenced code blocks for anything literal. Code, stack traces, and command output belong between triple backticks. Type those fences, then paste or dictate the surrounding explanation. Dictation is for describing the error, not for reproducing the exact bytes of a log line.
The result is a comment where the writing is fast and human and the formatting is correct, which is a better trade than typing everything by hand just to keep the backticks in flow.
Getting technical vocabulary right
The one place generic dictation tends to stumble is on the vocabulary that fills a developer's writing: library names, class names, config keys, and acronyms that are not English words. You do not want to see "Cuban Eddie's" when you said "Kubernetes," or "post grey SQL" for "PostgreSQL."
Voice Keyboard Pro handles this with Smart Vocabulary, a personal dictionary with replacement rules. You add the terms you use constantly, spelled and capitalized exactly the way you want them, and the app applies them automatically. Add your framework and tool names, your service and repository names, the function and variable identifiers that come up in review, and the acronyms your team throws around. Once OAuth, nginx, PostgreSQL, and your own UserSessionManager are in the dictionary, they come out right every time instead of being re-typed after every dictation.
This is the same reason dictation works well for other code-adjacent writing. If you want it inside your editor and command line too, our guides on dictation for coding and voice-typing git commits in the terminal go deeper on building a vocabulary that fits your stack.
Fixing mistakes without retyping
No dictation is perfect, and the difference between a tool you keep and one you abandon is how painless the corrections are. On iPhone, Voice Keyboard Pro includes Voice Edit: instead of tapping backspace and retyping, you speak the change you want. If a sentence in your issue came out with the wrong word, you say what it should say and the text updates in place. For quick fixes on a phone screen, that is far less fiddly than positioning a cursor between two characters with your thumb.
On Mac, corrections are usually a matter of clicking into the spot and dictating the replacement, or just typing it, since your hands are already on the keyboard. The two input methods coexist. Dictate the paragraph, then fix the one word by hand. Most people settle into a hybrid where voice does the bulk and the keyboard does the surgery.
Writing GitHub issues and reviews that are actually good
Dictation does not just make writing faster, it changes what you are willing to write. A few habits that voice makes easy:
- Narrate the reproduction, do not summarize it. Talk through the exact steps as if walking someone to your screen. "I opened the settings page, clicked save with an empty email field, and the app showed a blank error instead of a validation message." That level of detail is tedious to type and effortless to say.
- Explain the why in your PR, not just the what. The diff already shows what changed. Use the description to say why this approach over the obvious alternative, and what you decided to leave for later. Two spoken paragraphs here save your reviewer ten minutes of guessing.
- Make review comments kind and complete. "This could leak a connection if the request throws before close, want to wrap it in a defer?" reads very differently from "leak here." Voice makes the fuller, friendlier version cost almost nothing.
- Write the docs you keep skipping. The README section, the onboarding note, the runbook step. These get skipped because typing them feels like overhead. Dictated, they take a couple of minutes.
For teams, the compounding effect is real. Issues that reproduce cleanly get fixed faster. PRs with clear reasoning get reviewed faster. Discussions where people actually made their argument reach decisions faster. The bottleneck was never thinking, it was the friction of typing it all out.
A note on privacy
Developers care about where their words go, and issue text can reference internal systems, unreleased features, and security details. Voice Keyboard Pro is built so that your dictation content is not stored on our servers. The transcription engine processes your audio to return text, and what we keep on the backend is limited to operational pings, not your audio and not the transcript of what you said. Your bug reports and review comments are yours.
If private-by-default dictation is a priority for you across the board, our overview of private voice to text on Mac explains the approach in more detail.
Free tier and Pro
Voice Keyboard Pro has a free tier with a generous daily allowance, which is plenty to try dictating your next few issues and comments and decide whether it fits your workflow. If you find yourself living in GitHub and reaching for voice all day, Pro removes the daily limits and unlocks the full feature set for $4.99 per month or $34.99 per year. Pro spans both the Mac app and the iPhone keyboard, so one subscription covers dictating a review at your desk and filing an issue from your phone.
Frequently asked questions
Does dictating in GitHub need a browser extension?
No. On Mac, Voice Keyboard Pro types at the cursor across the whole system, so it works in GitHub's web interface in any browser with nothing to install per site. On iPhone, it is a keyboard, so it works inside the GitHub app and in Safari alike.
Can I dictate code with it?
You can dictate code-adjacent prose easily, and short identifiers dictate fine once they are in Smart Vocabulary. For literal code, stack traces, and command output, use fenced code blocks and paste or type the exact characters. Dictation is best for the human language around the code, not for reproducing exact syntax character by character.
Will it get my framework and library names right?
Yes, once you add them. Put your tools, services, repository names, and common identifiers into Smart Vocabulary with the exact spelling and capitalization, and they come out correctly every time instead of needing a fix after each dictation.
Does it work with GitHub Enterprise?
Yes. The app does not integrate with GitHub directly, it types into whatever text field has focus, so it works the same on github.com, GitHub Enterprise, and any self-hosted instance you reach through a browser or the mobile app.
Is my issue text private?
Your dictation content is not stored on our servers. The backend keeps operational pings only, not your audio or your transcripts, so the words you speak into a GitHub comment stay yours.
Start dictating your next issue
The next time you have a bug to file or a pull request to explain, try talking it through instead of typing it. Open the box, hold your hotkey or tap the mic, and describe the problem the way you would to a teammate. The writing that used to feel like overhead becomes the fastest part of the task, and your issues, PRs, and reviews get clearer as a side effect. Download Voice Keyboard Pro and dictate your next GitHub comment to feel the difference.