Short answer: Dictation usually breaks after sleep because macOS re-enumerates audio devices on wake and your app is still pointed at the old one. Check System Settings, Sound, Input and watch the level meter first, reconnect any Bluetooth headset, then restart Core Audio with sudo killall coreaudiod.
Everything worked when you closed the lid. You open it the next morning, press your dictation key, and nothing happens. No chime, no indicator, no text. Every other part of the Mac came back fine: the trackpad responds, Wi-Fi reconnected on its own, Mail is already syncing. Only dictation is dead.
Then you restart the Mac and it works again, which is the most annoying possible outcome, because a fix that works without explaining anything guarantees the problem comes back tomorrow.
This is a specific and well-understood failure, and it is almost never a problem with dictation itself. It is a problem with the microphone your Mac thinks it is listening to. Below is what actually happens during a sleep cycle, a thirty-second test that tells you which half of the problem you have, and nine fixes ordered by how often each one is the real cause.
Why sleep breaks dictation when nothing else breaks
Sleep is not a pause button. When your Mac sleeps, it suspends and powers down a large amount of hardware, and audio input is one of the first things to go, because a microphone that nobody is listening to is pure battery cost. Wi-Fi, by contrast, is designed to hold state and reconnect gracefully, which is why the network is usually back before you have finished typing your password.
Audio has no equivalent guarantee. On wake, macOS rebuilds its picture of what audio hardware exists:
- The built-in microphone is re-registered, usually within a second or two.
- Bus-powered USB devices renegotiate their connection, and anything behind a hub or dock has to wait for the hub itself to come back first.
- Bluetooth headsets re-pair on their own schedule, which can be several seconds after the screen is already on and you are already trying to speak.
- Virtual audio devices installed by conferencing and screen-recording tools re-register whenever their background process gets around to it.
The order in which those things finish is not fixed. It varies with what is plugged in, how long the Mac slept, and whether the lid was closed or the display just turned off. So the device list your Mac had before sleep and the device list it has thirty seconds after wake are frequently not the same list in the same order.
An application that grabbed a reference to an input device before sleep can end up holding a reference to something that no longer exists, or to a device that exists but is no longer the one connected to your voice. And here is the part that makes this so hard to diagnose: a microphone that returns silence is indistinguishable from a quiet room. Nothing errors out. Nothing turns red. The app records what it believes is audio, gets a flat line, and either produces nothing or produces a single wrong word.
The failure is almost never "dictation is broken." It is "dictation is recording from a device that is not listening to you."
That reframe matters, because it tells you which fixes are worth trying and which ones are superstition.
Thirty seconds of diagnosis before you change anything
Do this first. It splits the problem in half and saves you from working through eight irrelevant fixes.
- Open System Settings, go to Sound, then the Input tab.
- Look at which device is selected.
- Talk at a normal volume and watch the input level meter.
Three possible outcomes, and each sends you somewhere different:
The meter moves and the right device is selected. Your microphone is fine at the operating system level. The problem is in the dictation layer: permissions, a hung background process, or an app that cached a stale device. Go to fixes 5 through 8.
The meter is completely flat. The problem is below dictation. Nothing you change in a dictation app will help until the OS can hear you. Go to fixes 1 through 4.
The wrong device is selected, for example a monitor's built-in microphone, a webcam, a virtual device from a meeting app, or headphones that are in the room but not on your head. This is a routing problem and it is the single most common cause of the post-sleep version of this bug. Fix 1 handles it.
If you want a second opinion, open Voice Memos and record five seconds. If the waveform is flat there too, you have confirmed an OS-level audio problem and you can stop looking at dictation settings entirely.
Fix 1: Reselect the input device, even if it looks correct
In System Settings, Sound, Input, click a different device, wait two seconds, then click back to the one you want. This forces macOS to tear down and rebuild the input route.
This sounds too simple to work, and it resolves this specific post-sleep failure more often than anything else on this page. The selection you see in the interface is the name macOS remembers. It is not proof that the underlying connection is live. Reselecting makes the OS actually re-establish it.
If the device you want is not in the list at all, it has not come back from sleep yet. Wait ten seconds and check again before unplugging anything.
Fix 2: Bluetooth headsets reconnect on their own schedule
AirPods and other Bluetooth headsets are the biggest single source of post-sleep audio confusion, because they introduce a race that nothing on your Mac controls. When you wake the Mac, the headset may reconnect immediately, several seconds later, or not until you take them out of the case and put them back.
Worse, a headset can connect for output before it connects for input. During that window your Mac is playing sound to the headset while still listening through a different microphone, or through a headset microphone that has not finished negotiating. If you start dictating in that window, you get silence or garbage.
What to do:
- Give the headset a few seconds after wake before you dictate. This alone fixes the intermittent version of the problem.
- If it is already connected but dead, toggle Bluetooth off and on, or put the earbuds back in the case and take them out again.
- If you do not actually need the headset microphone, set your input to the built-in microphone permanently and leave the headset for output only. The built-in microphone on a modern Mac is genuinely good, and it always comes back on wake.
There is more detail on the headset-specific version of this in our guide to Mac dictation not working with AirPods, including why the audio quality drops when a headset switches into microphone mode.
Fix 3: Docks, hubs, and USB microphones
If your microphone or audio interface is plugged into a dock, a display, or a hub, you have added a second device that also has to wake up, and it has to finish waking before the microphone behind it can register.
Symptoms that point here: dictation is reliable when the Mac is undocked and broken when it is docked, or broken specifically on the first wake after arriving at your desk.
Things worth trying, in order:
- Unplug the microphone from the dock and plug it directly into the Mac to confirm the dock is the variable.
- Unplug and replug the dock's upstream cable after wake, which re-enumerates everything behind it at once.
- If the microphone is bus-powered and marginal, try a powered hub or a direct port. Bus-powered devices are the ones most likely to fail the wake negotiation.
- Check for a firmware update for the dock. Sleep and wake handling is one of the most common things dock firmware updates fix.
Fix 4: Restart Core Audio
macOS runs a background process that manages all audio routing. When it gets into a bad state across a sleep cycle, every audio app on the machine misbehaves at once and nothing in System Settings appears wrong.
You can restart it without restarting the Mac. Open Terminal and run:
sudo killall coreaudiod
Enter your password when prompted. Audio will cut out for a second or two and then come back. The process restarts automatically, so there is nothing to turn back on. Anything currently playing audio may need to be restarted, so it is worth quitting a running call before you do this.
This is the closest thing to a real answer to "why does restarting fix it." A full restart works because it restarts this process along with everything else. Restarting just this process gets you the same result in two seconds instead of two minutes.
If this fixes it every single time and you have to run it every morning, that is a strong signal that something specific on your machine is upsetting audio on wake, usually a virtual audio device from a conferencing or recording tool. See fix 9.
Fix 5: An app that woke up first took the microphone
Some applications relaunch or reconnect on wake, and conferencing tools are the worst offenders because they are designed to be ready before you need them. If one of those grabs the input and changes the system route, your dictation ends up recording from wherever that app decided to point.
Check the menu bar for the orange microphone-in-use indicator. If a small dot is showing and you are not in a call, click Control Center to see which app is using the microphone.
Quit any conferencing app completely, not just close its window. Many of them keep running in the menu bar. Then reselect your input device as in fix 1 and test again. If that resolves it, consider removing the offending app from Login Items so it stops racing you every morning.
This is closely related to the problem covered in Mac dictation keeps stopping, where a second app interrupting the input mid-session cuts a recording short.
Fix 6: The dictation language assets did not reload
This one applies to Apple's built-in dictation specifically. It relies on downloaded language assets, and after a sleep cycle or an interrupted download those assets can be present but not loaded, which produces a dictation feature that turns on, shows its indicator, and transcribes nothing.
Go to System Settings, Keyboard, then Dictation. Switch the dictation language to something else, wait for it to settle, then switch back to your language. That forces a reload. If a download stalls at this point, our guide to a stuck Mac dictation download covers how to clear it.
Toggling dictation off and back on in the same panel is worth doing at the same time. It costs five seconds.
Fix 7: Permissions are granted but the listener is not running
Dictation tools that work system-wide need permission to watch for a keypress. On macOS that means Accessibility, and sometimes Input Monitoring, in System Settings under Privacy and Security.
The trap is that these permissions can show as granted while the process that uses them is no longer running or no longer registered. The checkbox reflects a stored preference, not a live connection.
If the app's own indicator never appears when you press the key, the keypress is not reaching it at all:
- Open System Settings, Privacy and Security, Accessibility.
- Turn the app's toggle off, then on again. You may be asked to authenticate.
- Quit the app fully and relaunch it.
- Repeat under Input Monitoring if the app appears in that list.
Toggling off and on is meaningfully different from just looking at the toggle. It re-registers the app with the permission system.
Fix 8: The app did not survive wake as cleanly as it looks
An app can be present in the menu bar and still be in a broken internal state, particularly if it holds a connection that timed out during sleep. The icon is drawn from memory. It does not prove the app is healthy.
Quit it properly and relaunch. For menu bar apps that means using Quit from the menu, not closing a window. If dictation works immediately after relaunch, you have found your answer, and the question becomes whether that happens every wake or only occasionally.
Occasionally is normal for any long-running background process. Every single wake is a bug worth reporting, with the detail that it happens on wake specifically.
Fix 9: When it happens on every single wake
If you are running killall coreaudiod or relaunching something every morning, stop treating it as a fix and start isolating the cause.
Audit your virtual audio devices. Open the Audio MIDI Setup app, in Applications, Utilities. Anything in the device list that is not real hardware was installed by software: meeting tools, screen recorders, audio routing utilities, streaming apps. These are the most common cause of chronic wake-related audio breakage. Uninstall any you no longer use, using the vendor's uninstaller rather than dragging the app to the Trash, because the audio driver component lives outside the app bundle.
Test in a new user account. Create a fresh account in System Settings, Users and Groups, log into it, and sleep and wake the Mac. If dictation survives wake in the new account, the cause is something in your normal account: a login item, a background agent, or a preference. If it breaks there too, it is system-level or hardware.
Check whether it correlates with lid-closed sleep. Closing the lid on a Mac connected to an external display is a different scenario from the display simply turning off, and it exercises more of the display and dock wake path. If only lid-closed sleep breaks dictation, your external gear is involved.
Consider a recent macOS update. If this started the week a major version landed, you are likely not alone, and the practical fix is usually the next point release. In the meantime, our post-update dictation checklist covers permissions and settings that get reset during an upgrade.
One note on resets: on Apple Silicon Macs there is no NVRAM reset key combination to press. Apple Silicon handles that automatically on restart, so advice you find recommending a specific startup key sequence is written for older Intel machines and does not apply.
Why "just restart it" is a bad answer
Restarting works because it rebuilds every piece of state involved at once: the audio daemon, device registrations, permission connections, and every background process. It is a shotgun.
The cost is that it teaches you nothing, so the same twenty seconds gets spent every morning, and the underlying cause never gets found. The fixes above are ordered so that the cheap, high-frequency ones come first. In practice, reselecting the input device and giving a Bluetooth headset a moment to settle resolve the large majority of post-sleep dictation failures, and neither requires closing your work.
The design difference that matters here
There is a real architectural distinction between dictation tools that hold a long-lived recording session and tools that capture per press.
A tool that opens an audio session when it launches and keeps it open all day has to survive every sleep cycle, every headset reconnect, and every dock event with that session intact. When one of those events invalidates the session, the tool is holding a handle to something that no longer works, and it usually will not find out until you speak into it.
Voice Keyboard Pro works the other way round. You hold your key, speak, and release, and the words land at your cursor in whatever app you are in. Because each capture starts when you press the key, there is no all-day session sitting open across a sleep cycle waiting to go stale. That does not make it immune to a microphone that genuinely failed to come back, since no application can fix hardware the operating system cannot see, but it removes one of the most common ways this failure happens.
The other practical benefit is that the diagnosis above stays valid. If the input meter in System Settings moves, a per-press tool has something to record. If it does not, you know immediately that the problem is below the app and you go fix the route.
If you dictate on iPhone too
iPhone does not have the same sleep and wake problem, because it does not tear down audio the way a Mac does when the lid closes. What it has instead is a set of app-switching and permission issues that look similar from the outside. If dictation on your phone stopped after an update or stops mid-sentence, those are separate causes with separate fixes.
Voice Keyboard Pro's iPhone keyboard puts a microphone button in the keyboard itself, so you can dictate in any app rather than depending on whatever a particular app offers. It also supports Voice Edit, where you speak a correction instead of tapping to reposition the cursor, and two-way translation while dictating across 24 languages.
What none of this fixes
Being straight about the limits:
- Hardware failure. If the input meter is flat with the built-in microphone selected, in a new user account, after a Core Audio restart, the microphone or its connection has a physical problem. That is a hardware service question, not a settings question.
- A room that is too loud. Wake is a coincidence in some of these reports. If you moved from a quiet home office to a café, accuracy problems have a different cause. Our notes on dictating in background noise cover that case.
- A microphone your Mac never sees. If a USB device does not appear in Audio MIDI Setup at all, the problem is the connection or the driver, and no amount of dictation configuration will surface it.
Frequently asked questions
Why does dictation work again after a restart but break on the next wake?
Because the restart rebuilt the audio state and the wake broke it again. The cause is whatever fails during your specific sleep cycle, most often a Bluetooth headset, a dock, or a virtual audio device installed by a meeting app. Fix 9 walks through isolating it.
Is sudo killall coreaudiod safe to run?
It restarts the audio process, which macOS immediately relaunches. Audio drops for a second or two. Quit any live call first, since the call app may need to reconnect its audio.
Why does this happen more when my Mac is docked?
A dock adds a device that has to wake before anything behind it can register, and the wake ordering is not guaranteed. Plugging a microphone directly into the Mac is the fastest way to confirm the dock is the variable.
Does closing the lid matter, or is any sleep the same?
They are not identical. Lid-closed sleep with an external display exercises more of the display and dock wake path. If dictation only breaks when you close the lid, your external gear is part of the cause.
Will a different dictation app fix this?
Only if the cause is in the app layer. If your input meter is flat, the problem is below every dictation app on the machine and swapping tools changes nothing. If the meter moves and one app fails while others work, the app is the variable, and a tool that captures per press rather than holding a session open all day has fewer ways to go stale across a sleep cycle.
Should I just turn off sleep?
It works, and it costs you battery life and puts unnecessary wear on the machine. Fixing the device route is the better trade in almost every case.
The words land at your cursor in whatever app you are already in — Mail, Slack, Word, a browser form. No dictation window, nothing to copy across.
Free forever for casual use · Apple Silicon & Intel