How to Dictate in Jupyter Notebook on Mac

← Back to Blog

Short answer: Dictate in Jupyter Notebook by putting the cell into edit mode first, then holding your dictation hotkey and speaking. Use voice for markdown cells, docstrings, and comments where it is genuinely faster. Type the code itself. Add library names to a personal dictionary so they transcribe correctly.

Jupyter notebooks are a strange environment for dictation, and most people who try it give up in the first ten minutes. They click a cell, hold the hotkey, speak a sentence, and watch the notebook create three new cells and jump to the bottom. The conclusion is that dictation does not work in Jupyter.

It does. But it requires understanding one thing about how notebooks handle keyboard input, and being honest about which parts of a notebook are worth dictating in the first place. This guide covers both, plus the practical details of library names, numbers, and the workflow that actually makes voice pay off in analysis work.

The one thing that breaks dictation in Jupyter

Jupyter is modal. At any moment a cell is in one of two states, and this is not decoration, it changes what every key on your keyboard does.

Command mode (blue cell border, no cursor in the cell). Letter keys are shortcuts. Pressing a inserts a cell above. b inserts below. dd deletes the cell. m converts to markdown. y converts to code.
Edit mode (green cell border, blinking cursor inside the cell). Keys type characters, as you would expect.

If you dictate while the notebook is in command mode, your text is not typed anywhere. Every letter is interpreted as a command. That is why people see cells appearing and disappearing seemingly at random. The notebook is faithfully executing "insert cell below, insert cell below, merge, delete" because those happened to be the letters in your sentence.

The fix: before you dictate anything, press Enter or click directly inside the cell body. Confirm you see a blinking cursor. That is edit mode. Now dictate. When you are done, press Esc to go back to command mode, then Shift+Enter to run the cell.

Make the cursor check a reflex. Click, look for the cursor, then speak. It takes half a second and it eliminates the single most common failure mode by a wide margin.

What is actually worth dictating in a notebook

This is where most guides get unhelpfully enthusiastic. Dictating code is a bad idea, and pretending otherwise wastes your time.

Code is dense with syntax that has no natural spoken form. Brackets, colons, underscores, dots, and indentation all have to be spoken as explicit commands, and by the time you have said "open bracket quote revenue quote close bracket" you could have typed it three times over. Speech is fast for prose and slow for punctuation-heavy strings. That is not a limitation of any particular tool, it is a property of the medium.

But a notebook is not only code. Here is where voice genuinely wins.

Markdown cells

This is the biggest one. Markdown cells are pure prose, and prose is exactly what dictation is fast at. A notebook that will be read by anyone other than you needs explanatory cells: what this section does, why the data was filtered this way, what the chart shows, what the caveats are.

These cells are also the ones people skip most often, because writing them feels like a chore after the analysis is already working. Speaking them takes a fraction of the time. Adults type at roughly 40 words per minute and speak at 130 to 150, and a three-sentence explanation is exactly the kind of thing where that gap compounds into real time saved.

Docstrings

Function docstrings in notebook cells are prose wrapped in quotes. Type the triple quotes, dictate the body, type the closing quotes. The description, the parameter explanations, and the returns section are all natural language, and dictating them removes the friction that causes docstrings to be one terse line or absent entirely.

Comments explaining the why

The comments worth writing are the ones that explain reasoning, not mechanics. "We drop the first two weeks because the tracking script was not deployed yet" is a sentence, and sentences dictate well. Type the #, then speak.

Analysis narrative and findings

When you have a result and need to write up what it means, dictation is at its best. This is the part of the work where you already know what you want to say and the only bottleneck is getting it down. Speaking your interpretation of a chart while looking at the chart produces better writing than typing it, because you are not context-switching into typing mode.

The README and the summary at the top

Every notebook should start with a cell explaining what it is. Almost none do. Dictating that cell takes under a minute.

Setting up on a Mac

The setup is straightforward because Jupyter runs in a browser or in an editor, and both are ordinary Mac apps.

Install a system-wide dictation tool. Anything that types at your cursor works, because Jupyter has no dictation of its own and no plugin is required. Voice Keyboard Pro sits in the menu bar: hold a hotkey, speak, release, and the text appears wherever your cursor is.
Grant microphone and accessibility permissions when prompted. Accessibility is what allows text to be inserted into other apps.
Pick a hotkey that Jupyter does not use. This matters more in Jupyter than in most apps, because the notebook claims a lot of keys. A modifier-based hotkey is safest.
Test in a markdown cell. Create a cell, press m to make it markdown, press Enter to get into edit mode, and dictate a sentence. If it lands in the cell, you are set.

Because the tool inserts at the cursor rather than integrating with Jupyter, it works identically across JupyterLab, the classic Notebook interface, Notebook 7, VS Code's notebook editor, and hosted notebooks in a browser tab. There is nothing to configure per environment.

Environment-specific notes

JupyterLab

JupyterLab adds panels, so there are more places your cursor can be. If dictated text is not appearing, check that focus is in the notebook cell and not the file browser or a terminal panel. Clicking directly on the text in the cell is the reliable way to be sure.

VS Code notebooks

If you open .ipynb files in VS Code, the modal behaviour still applies, though the visual cues differ. VS Code also brings its own set of keyboard shortcuts, so hotkey conflicts are slightly more likely. If you already dictate in VS Code for regular Python files, the same setup carries over. Our guide to voice to text for developers covers the general editor workflow.

Hosted notebooks in the browser

Cloud-hosted notebooks behave like any other web app. The one extra thing to watch is autosave and cell focus during a sync. If you dictate immediately after the page reports saving, give it a beat so the field is ready to receive text.

Launching from the terminal

If you start Jupyter from a terminal, you can dictate there too, though command syntax has the same problem code does. Long flags and paths are faster typed. See voice typing in the terminal for where the line falls.

Library names, and why they get mangled

This is the second thing that makes people give up. You say "pandas" and get "panda's." You say "numpy" and get "numb pie." You say "matplotlib" and get something unrecognisable. You say "scikit-learn" and get "psychic learn."

This is not a defect in transcription. These are words that do not exist in ordinary English, or worse, they sound identical to words that do. No transcription engine can know from audio alone that you meant a library and not an animal.

The fix is a personal dictionary. Voice Keyboard Pro's Smart Vocabulary lets you add terms with replacement rules, so the sounds you make consistently produce the spelling you want. Terms worth adding for notebook work:

Library and framework names you use daily
Your column names, especially ones that are abbreviations
Internal dataset names, table names, and system names
Domain jargon specific to your field
Colleagues' names, for notebooks that get shared and annotated

Set this up once and it applies everywhere you dictate, not just in Jupyter. It is the difference between dictation being a novelty and being something you use every day. The same principle applies to any technical writing surface, which we cover more broadly in our guide for data scientists.

Numbers, units, and statistics

Notebook prose is unusually number-heavy, and numbers are where dictation gets fiddly. A few practical habits:

Say numbers naturally and fix the format after. Trying to control digit-by-digit formatting while speaking breaks your flow. Speak the sentence, then adjust.
Percentages usually work. "Twelve percent" typically comes out sensibly.
Be explicit with decimals. "Zero point three four" is clearer than "point three four."
For precise figures, type them. If a number has to be exactly right in a written finding, typing four characters is faster than checking whether dictation got it right.

The general principle holds: dictate the sentence around the number, type the number when precision matters.

A workflow that actually works

The mistake is trying to dictate while you are figuring things out. Exploration is a keyboard activity: you are running cells, tweaking parameters, reading errors, and none of that involves prose.

The better pattern is to separate the two modes.

Phase one, keyboard. Do the analysis. Write the code, run the cells, get the charts right. Leave the markdown cells empty or with a one-word placeholder. Do not stop to document.

Phase two, voice. When the analysis works, go back to the top and do a documentation pass. Click into each empty markdown cell, hold the hotkey, and explain what the section below it does. You are looking at working code and real output, so you know exactly what to say. This pass is fast because you are not thinking about the analysis anymore, only describing it.

A notebook that took two hours to build might get fully documented in ten minutes this way. The reason it usually does not get documented at all is that typing the explanations after the fact feels like a second job. Speaking them does not.

The documentation pass is the part of notebook work that everyone skips and everyone later wishes they had not. It is also the part where voice is fastest.

Common problems and fixes

Text is creating and deleting cells

You are in command mode. Press Enter or click inside the cell body first. This is cause number one and it accounts for most reported failures.

Text lands in the wrong cell

Focus moved between when you clicked and when you spoke, usually because a cell finished running and the notebook scrolled. Click the target cell again, confirm the cursor, then dictate.

Nothing appears at all

Check accessibility permission for your dictation tool in System Settings, and confirm the cursor is in a cell. Test in TextEdit to isolate whether the problem is Jupyter-specific or system-wide.

The hotkey does something in Jupyter instead of starting dictation

A shortcut conflict. Change your dictation hotkey to a combination Jupyter does not claim.

Markdown formatting is not applied

Dictation inserts plain text. Markdown syntax like ## for headings or asterisks for emphasis has to be typed, or spoken as explicit characters. In practice, typing the two hash marks and dictating the heading text is the fastest combination.

Long explanations come out as one block

Paragraph breaks need to be handled deliberately. Dictate a paragraph, press Return manually, dictate the next. Trying to speak the structure and the content at the same time is slower than doing them separately.

Beyond the notebook

Most notebook work does not end in the notebook. There is a summary for a colleague, a message in a chat thread, a ticket, a section of a paper, or a set of slides. All of those are prose, and all of them dictate well.

If your work feeds into papers or literature reviews, voice to text for academic research covers that side. And if you also write Swift or work in Xcode alongside your Python, dictating in Xcode follows the same prose-not-syntax principle.

Voice Keyboard Pro also runs on the iPhone as a custom keyboard with a built-in mic button, which means the same dictation works in any iOS app. Useful when a thought about the analysis arrives away from your desk and you want it captured properly rather than thumb-typed.

On privacy

Notebook work often touches data that should not leave your organisation. Worth being precise about what happens: the server stores only operational pings. No audio is retained, and no transcript content is stored on the server.

That said, apply your own judgement. If your organisation has rules about cloud services processing work content, those rules apply here as they would to any tool. The practical middle ground for sensitive projects is to dictate the general narrative and type the specifics.

The summary

Get into edit mode first. Press Enter or click in the cell. Look for the blinking cursor before you speak.
Dictate prose, type code. Markdown cells, docstrings, and why-comments are the wins. Syntax is not.
Add your library and column names to Smart Vocabulary. One setup, permanent fix for the mangling.
Separate the phases. Analyse with the keyboard, document with your voice in one pass at the end.
Type precise numbers. Dictate the sentence around them.
Pick a hotkey Jupyter does not claim. The notebook uses a lot of keys.

Voice Keyboard Pro has a free tier with daily limits, and Pro is $4.99 a month or $34.99 a year. The honest test is the documentation pass: take a notebook you finished and never explained, and try speaking the markdown cells. If that pass takes ten minutes instead of an hour, the workflow is worth keeping.