Google Meet Camera Blocked: Undoing a Permission You Denied

A camera icon with a line through it sits in the address bar, the video tile shows a name instead of a face, and Meet says the camera is blocked. Nothing about the message says who blocked it or where the decision is stored, which is why this turns into a hunt.

The word blocked is doing a lot of work in that sentence. It can mean a stored answer from a previous visit, a system level switch, a policy set by an administrator, or another application holding the device. Those four live in four different places, and three of them are reversible in under a minute once identified. The hardware is almost never the problem, and a Mac that shows a working picture in Photo Booth has already proved that.

What blocked means in that message

A camera request on a Mac passes through several gates before it reaches the sensor. Meet reports a refusal at any of them with roughly the same wording.

What you are looking at	Which gate refused	Where the answer is stored
A crossed out camera icon in the address bar	The site permission	The browser profile, per site
No camera listed at all in Meet's video settings	The system permission	macOS Privacy and Security
A black tile with the camera indicator light off	Another app holding the device	Nowhere, it is a live conflict
A permission control that is greyed out and cannot be changed	An administrator policy	A managed configuration profile

The distinction between the first two rows is the one worth learning. A site level block means the browser has the camera and is refusing to hand it to this page. A system level block means the browser does not have the camera at all, so no page in it can get one. The first is fixed in the browser, the second is fixed in System Settings, and doing the wrong one produces no visible change and a strong impression that nothing works.

Apple's own note on the system list is a useful test. If nothing appears in the camera list, no installed app has asked for the camera yet. Built in apps such as FaceTime and Photo Booth are given access without asking. So a browser that is missing from the list has never made the request, which is a different situation from a browser that was denied.

Reversing a site level block

In Chrome the path is Settings, then Privacy and security, then Site settings, then Camera. The page shows both the sites that were allowed and the sites that were blocked.

Two controls matter. Selecting a site's name opens its own page, where the camera setting can be changed back to Allow. Choosing Delete next to the site clears the stored answer instead of changing it, which means the prompt appears again on the next visit. Deleting is usually the better move, because it puts the decision back in front of you at the moment you actually need the camera, rather than leaving a permanent grant in place.

The same page carries a down arrow for choosing the default camera the browser offers to sites, which matters on a Mac with a built in camera and an external one attached.

How the block got there is worth knowing, because it explains why this happens to careful people. When a site asks, the prompt offers choices along the lines of allowing while visiting the site, allowing this time, or never allowing. That last option is a permanent answer given in one click, often while a meeting is already starting and the prompt is in the way. It does not expire and there is no reminder that it exists.

One detail decides whether the right entry is being edited. The answer is stored against the site that asked, and the site that asks for a Meet camera is the one in the address bar. A meeting joined from a calendar link runs on Meet's own address and stores its answer there. A meeting embedded inside another product's page stores the answer against that product's address instead, so the Meet entry can look perfectly healthy while the block sits under a name nobody thought to check. Sorting the Site settings list and reading the addresses, rather than searching for the one expected name, is what finds that case.

Site answers are stored per browser profile. A second profile, a guest window or a different browser starts with no answer and asks again. That is occasionally the fastest workaround in the middle of a call, and it is also why the same block seems to reappear: it was never fixed in the profile that keeps being used.

Reversing a system level block

The path is the Apple menu, then System Settings, then Privacy and Security in the sidebar, then Camera. Access is turned on or off for each app in the list.

Three details decide whether this works on the first attempt.

Quit the app and open it again after changing the switch. A running browser can hold the earlier answer for the rest of its session, and Quit means Quit rather than closing the last window. This single step accounts for most reports that the toggle did nothing.

The green light next to the camera is the confirmation to look for. It glows whenever the camera is on, and it goes out when every app that can use the camera is closed or quit. If the switch is on, the browser has been restarted, and the light still does not come on when Meet opens the video preview, the refusal is happening somewhere other than this setting.

An app missing from the list cannot be added by hand. The list is built from apps that have asked. If a browser is absent, open Meet in it and let the page request the camera, which produces the macOS prompt and the list entry at the same time.

On a Mac issued by a company or a school, a configuration profile can set these controls centrally, and a control set that way cannot be changed locally. A greyed out switch, or a browser setting that shows as managed, is the signature. There is no local workaround for that case and the request goes to whoever administers the Mac.

Both permissions are on and the tile is still empty

At this point the browser has the camera and Meet has been allowed to use it, so the remaining candidates are the device and what else is using it.

Check which camera Meet selected. In Meet, open Settings, then Video, and look at the Camera selection. If the camera is working, the video feed appears to the right of Video. The same panel holds Send resolution, which is the quality other people see, and Receive resolution, which is the quality you see, and it closes with Done. A stored selection pointing at an external camera that is no longer attached is a common cause of a tile that never lights up.

Exclusive use by another application is the other common cause. Anything that opens the camera holds it while it runs: a second meeting left open in another window, a recording tool, a virtual camera utility, or a video app minimised hours ago. The camera indicator light is the diagnostic. A light that is already on before Meet is opened means something else has the device.

External cameras add two further cases. USB cameras that draw power from the bus sometimes enumerate after the Mac wakes without producing a signal, and unplugging and replugging is the fix. An iPhone presented to the Mac through Continuity Camera appears as another device in the list and can become the stored selection, which produces an empty tile when the phone is in another room.

If the picture appears but is poor or unstable rather than absent, Google's stated requirements are the thing to read. A dual core processor and 2GB of memory are the stated minimum, with 10th generation Intel i3, i5 or i7 class chips or AMD 3000 series Ryzen given as the minimum recommendation, and Apple Silicon listed at the optimal tier alongside a 1080p camera and a graphics card with WebGL 2.0 support.

Browser and system versions, briefly

Google lists the current version of Chrome, Firefox, Edge and Safari as supported browsers for Meet, and recommends running the current version of whichever one is used. For operating systems it supports the current macOS release and the two previous major releases.

That matters for this problem in one specific way. An old browser build can hold permission behaviour that no longer matches what the site expects, and a browser that has been open for weeks without restarting is running an update that has been downloaded but not applied. Quitting and reopening handles both at once, which is why it is worth doing before a longer investigation.

It also sets a boundary on what to expect. A Mac two releases behind the current macOS is still inside what Meet supports, so an old system on its own is not an explanation for a blocked camera.

A second browser is the fastest way to use this. Google's requirements list a built in web camera or an external USB camera alongside a broadband connection, and nothing beyond that. So opening the same meeting link in another supported browser separates the two possibilities cleanly: a working picture there means the device and the system are fine and the fault is a stored answer in the first browser, while the same blocked message in both points at the system permission or at another application holding the camera. That test takes twenty seconds and removes half the candidate list.

Why this keeps happening in one crowded browser

Nothing above is difficult. What makes it recur is where these answers are kept.

Permissions are stored per browser profile, and a browser holding a dozen services in one profile also holds one shared set of camera answers. A block dismissed in a hurry applies to a site, not to a moment, and it will be waiting the next time that site is opened. Extensions that manage tabs or media add behaviour that differs between profiles. And a Meet tab living among thirty others is a tab that gets closed, reopened and reloaded constantly, which is when a prompt appears at the worst possible time and gets the wrong answer.

A browser that gives each web application its own window and its own cookie container changes the arithmetic. The camera answer for the meeting application is given once, in a window that does nothing else, and it is not sitting next to the answers for every other service. The application is also its own entry in the macOS privacy lists, which makes the system level switch a single obvious row rather than one line covering everything a general purpose browser does. The feature list covers what that separation buys, and Meet is among the services on the supported applications list.

What to change first

Open Site settings, then Camera, find the Meet entry and choose Delete rather than changing it, so the prompt comes back fresh. Then open System Settings, then Privacy and Security, then Camera, confirm the browser's switch is on, and quit and reopen the browser afterwards. If the camera indicator light comes on at the Meet preview, the permission chain is intact and any remaining fault is the device selection.

If the meeting keeps getting buried in a window holding everything else you use, that is the part worth changing, and SpaceDeck is built for it.