When Google Chrome might not have screen recording permission in macOS
A call is running, the share button is pressed, and instead of a grid of screens and windows the dialog holds one sentence and a button labelled Open System Settings. Nothing is captured. The other side sees a static slide or nothing at all, and the usual reflex of clicking share again produces the same dialog.
The sentence in that dialog is precise, and reading it literally saves most of the time people spend on this. It names an application, a system setting, and a restart. All three are required, and the third is the one that gets skipped.
The message is about the application, not the website
Chrome ships two versions of this text, one for each kind of capture. When a screen is being shared it reads: To share your screen, allow screen recording for Chrome in System Settings. When a window is being shared it reads: To share your window, allow screen recording for Chrome in System Settings. Directly underneath, a second line is added: You'll then need to restart Chrome.
That wording matters because it locates the problem outside the browser's own permission model. A site asking for the camera produces a Chrome prompt with Allow and Block. This is not that. Chrome never reached the point of asking about the site, because macOS had already refused to hand the browser a picture of the display. The list of screens is empty because there is nothing the browser is allowed to enumerate.
The same distinction explains why clearing site data, resetting site permissions, or reinstalling a meeting extension changes nothing. None of those touch the operating system's answer. It also explains why the failure follows the browser rather than the service: every site that asks to capture the screen fails in the same way, at the same moment, with the same dialog.
The button in that dialog is a shortcut, not a fix. Open System Settings opens the right pane. The switch still has to be turned on by hand, and the browser still has to be relaunched afterwards.
Where Apple put the switch, and what it is called now
The pane changed names, which is why older instructions send people to a heading that no longer exists. Apple's current guidance describes the location and the granularity:
Choose Apple menu > System Settings, then click Privacy & Security in the sidebar. (You may need to scroll down.) Click Screen & System Audio Recording. For each app listed, turn the ability to record on or off. You can allow apps to record both your screen and audio, or just your audio. Source: support.apple.com
Two details in that passage are worth holding on to. The list is per application, so the grant belongs to the browser binary rather than to an account or a profile. And the add button below the list exists because an application that has never attempted a capture will not appear on its own. A freshly installed browser is absent from the list until it asks, or until it is added by hand.
The rename also has a practical consequence for searching. Results written before the pane was renamed refer to Screen Recording, and results written before System Settings replaced System Preferences refer to a different application entirely. The destination is the same in every version: the Privacy & Security section, the screen capture entry, the row for the browser.
Why the restart is part of the fix
The restart line is not a formality. Chrome states it as a required step rather than a suggestion, in a sentence of its own placed under the instruction about System Settings: You'll then need to restart Chrome. A browser that was already running when the switch was turned on can keep presenting the same dialog, the switch will continue to look correct, and the two facts together produce the conclusion that the setting did not take.
Quitting properly is the part that goes wrong on macOS. Closing the last window leaves the application running, and reopening a window from the Dock does not start a new process. The browser has to be quit outright, with the Quit command, and then launched again. On a Mac where the browser is set to launch at login, or where a background process is kept alive to receive notifications, it is worth confirming that the icon has actually disappeared before relaunching.
One case is worth a separate step. When a machine that worked last month starts failing with no setting having been touched, and the row is present and switched on, the remedy to try is to remove the row and add the current copy of the application back from the add button below the list. That is also the situation to check after a browser has been replaced or moved to a different folder, since the list is a list of applications rather than of names, and the entry has to correspond to the copy that is actually running.
A second dialog exists, and it asks for nothing
On recent versions of macOS the dialog can look entirely different, and the difference is deliberate rather than a fault. Chrome carries a separate set of texts for the case where the operating system supplies its own picker. Instead of an instruction about System Settings, the dialog reads: To share your screen, use your system's screen picker, with a button labelled Choose a screen. A variant reading Choose a screen with audio exists for the case where sound is included, and the window equivalent reads: To share your window, use your system's window picker.
Chromium describes the situation those texts belong to as one where there is a secondary, system-level picker in which the person must select the content to share. After a share has started, a further button appears reading Choose a different screen, and its purpose is to re-open that picker so a different monitor or desktop can be chosen.
The practical difference is where the decision lives. In this flow the selection is made in the system's picker at the moment of sharing, not in a setting that was turned on earlier, and the button to press is Choose a screen rather than Open System Settings. Reading the dialog is therefore the fastest way to know which of the two situations applies, and it is quicker than opening System Settings to check a row that may not be involved at all.
When it is not a permission problem at all
On a managed Mac the same symptom has a different cause, and turning switches on will never resolve it. Chrome's policy list includes an entry that governs screen capture outright, alongside four allowlists that carve out exceptions by origin: ScreenCaptureAllowedByOrigins, WindowCaptureAllowedByOrigins, TabCaptureAllowedByOrigins, and SameOriginTabCaptureAllowedByOrigins. Where one of those is in force, the answer is decided before the operating system is ever consulted.
Chrome labels this case in its own interface rather than leaving it silent. A narrowed list carries the line: Options for sharing are managed by your organization. Some items may be hidden. A blocked source shows Blocked by your admin in place of a preview. The page at chrome://policy lists every policy actually applied, which is the fastest way to separate a company rule from a system setting.
The distinction matters because the two look identical from the far side of a call. A missing system grant produces an empty list of sources and a dialog about System Settings. A policy produces a shortened list, a labelled explanation, or a blocked preview. Apple's own pane remains a per-application decision made on the machine, since the setting is described as turning the ability to record on or off for each app listed, so a managed configuration and a personal grant are separate steps rather than substitutes for each other.
| What appears | What is actually missing | Where it is resolved |
|---|---|---|
| To share your screen, allow screen recording for Chrome in System Settings | The macOS grant for the browser application | Privacy & Security, Screen & System Audio Recording, then a full restart |
| To share your screen, use your system's screen picker | Nothing in settings. The choice is made in the system picker | Choose a screen, at the moment of sharing |
| Options for sharing are managed by your organization | Policy has narrowed the list of sources | chrome://policy, then the administrator |
| Blocked by your admin | Policy blocks that specific tab or window | chrome://policy, then the administrator |
| Sharing starts but the audio is silent | The separate system audio grant | System Audio Recording Only for the browser |
The web platform also reports these cases distinctly, which helps when a support ticket contains a console error rather than a screenshot. In the documented exceptions for getDisplayMedia, a refusal by the person or by policy surfaces as NotAllowedError, thrown if the permission to access a screen area was denied by the user, or the current browsing instance is not permitted access to screen sharing. An operating system that hands back nothing to choose from surfaces as NotFoundError, thrown if no sources of screen video are available for capture. The second of those is the signature of a missing system grant.
System audio is a second grant, not part of the first
A share that works while the far side hears nothing is a separate problem with a separate switch, and Chrome states it in the same style: To share system audio, open System Settings and allow 'System Audio Recording Only' for Chrome. You'll then need to restart Chrome.
Apple's pane supports this split directly, allowing an application to record both the screen and the audio or only the audio. The practical consequence is that a machine can be fully configured for screen sharing and still be unable to pass through the sound from a video, and that fixing it needs its own restart. Anyone who prepares a Mac for presentations is better off setting both rows once, before the first call, than discovering the second one live.
The grant belongs to an application, which is the part that scales badly
Because the entry is per application, the cost of this configuration multiplies with the number of applications that capture the screen. A second browser kept for a separate work account needs its own row and its own restart. A dedicated desktop client for the same meeting service needs another. A recording tool needs another. Each one is a switch, a relaunch, and a chance to forget which copy holds the grant.
That is the point at which the shape of the setup, rather than the setting, is the variable. Keeping each web application in its own window inside a single browser means one application holds the screen recording grant, one row exists in Privacy & Security, and one restart covers everything. The reasoning behind separating applications into windows without multiplying browsers is set out in Workspaces, and the range of services people run this way is catalogued in Supported apps. For anyone weighing that against running several full browsers side by side, the trade-offs are laid out in Compared with Wavebox.
What to change first
Open Privacy & Security, switch on Screen & System Audio Recording for the browser, quit it completely, and launch it again. If the dialog instead offers a system picker, there is nothing to grant and the button to press is Choose a screen. If the number of separate applications each holding their own capture grant has become the real problem, SpaceDeck is built to keep that count at one.
Frequently asked questions
Why does Chrome say it might not have screen recording permission when the setting already looks enabled?
Almost always because the browser has not been restarted since the switch was changed. The grant is read when the process starts, so a running copy keeps behaving as though it were still denied. Quit the browser completely rather than closing its last window, then open it again.
Where is the screen recording setting on current versions of macOS?
Open the Apple menu, choose System Settings, click Privacy & Security in the sidebar, then click Screen & System Audio Recording. Each application has its own row. If the browser is not listed, use the add button below the list to add it.
Screen sharing works but the other side hears no sound. Is that the same permission?
No. Audio is a separate grant, and Chrome asks for it in a separate message that names System Audio Recording Only. Apple's pane allows an application to record the screen and the audio, or the audio alone, so both rows have to be set. That change also needs a restart.
On a work Mac the option is missing entirely. What now?
That usually means policy rather than a system setting. Visit chrome://policy to see what is applied, and look for the screen capture policy and its origin allowlists. Where a policy blocks capture, the browser reports it with its own wording, such as a note that options for sharing are managed by your organization, and adjusting System Settings will not change the outcome.
Why did screen sharing stop working after a browser update?
When the row is still present and switched on, the step to try is to remove that row and add the current copy of the application back using the add button below the list, then restart the browser. The list identifies applications rather than names, so an entry left over from a copy that has been replaced or moved is worth replacing before anything else is changed.