Google Meet Camera Not Working: Which App Is Holding the Camera

The meeting is live, the tile is black, and the camera works fine in FaceTime. That combination rules out hardware within about ten seconds and leaves a narrower question: something else on the machine, or something in the browser, is standing between Google Meet and a camera that is physically working.

On a Mac there are exactly three layers a video stream has to pass through, and they fail in ways that look identical from inside the meeting. Checking them in a fixed order takes under two minutes. Checking them at random, while a meeting is running, is how a five minute problem becomes a rescheduled call.

The three layers, and why the symptom is always the same

A camera frame reaching a Meet tile has to clear three separate gates.

The system gate is macOS. Apple's own description is that some apps can use the camera and the owner decides which ones, managed under System Settings, then Privacy & Security, then Camera. A browser that is unchecked there cannot see a camera no matter what any website asks for.

The browser gate is next. Chrome, Safari, Firefox and Edge each keep their own per site permission, and a site that was refused once stays refused. Google's own troubleshooting page makes the connection explicit: the Camera failed error often means the browser cannot access the camera.

The site gate is last, and it is the only one that produces a visible prompt. The first time a meeting is joined, camera access has to be allowed in that prompt, and the address bar keeps a camera control for changing the answer later.

Every one of those three failures shows up in the meeting as a black tile or a crossed out camera icon. That is why guessing does not work, and why the first useful move is not a setting at all but a test outside the browser.

Finding out which app is holding the camera

Google's list of first steps includes one that is easy to skip and often decisive: close other apps that use the camera, then reload Meet.

macOS gives a free indicator for this. Apple states that the camera turns on automatically when an app that can use it is opened, that a green light beside the camera glows while it is on, and that the camera and the light turn off when all apps that can use the camera are closed or quit. So the green light answers the question before any settings are opened. If it is lit while the Meet tile is black, something has the camera and it is not Meet.

The usual suspects are predictable, because they all open a camera at launch rather than on demand.

• A second video app left running from an earlier call, including one minimised or on another desktop
• Photo Booth or the Camera app, opened a minute ago to test the camera and never quit
• A second browser window or tab with a video service loaded, including a second Meet tab
• Recording or streaming software that claims the camera while idle
• A virtual camera or effects utility that sits between the hardware and every app

The diagnostic that separates hardware from permissions is also in Google's guide. Open the built in camera app, such as Camera or Photo Booth, and look at the self preview. If the preview shows an image and Meet does not, the hardware is fine and the problem is a permission. If the preview shows nothing either, check the physical camera cover or privacy switch, which some laptops have as a slider above the lens or a switch on the side, sometimes with an orange, red or amber light when engaged.

The macOS list only shows apps that already asked

This is the single most misleading part of the system gate, and it sends people looking for a checkbox that is not there.

Apple's guidance states that the list under Privacy & Security, then Camera, shows apps that have been installed and have asked to use the camera, and that if the list is empty no such app has been installed. Bundled apps including FaceTime and Photo Booth have access automatically and need no permission.

The consequence is that a browser appears in that list only after it has requested camera access at least once. A fresh Chrome install that has never been in a video call will not be listed, so an empty list is not evidence that anything is blocked. Joining a meeting once, allowing the prompt, and then looking again is what populates it.

Google's version of the same step names the versions involved: on macOS Mojave, version 10.14, or later, the browser has to be allowed to use the camera so that Meet can use it, by going to System Settings, then Privacy & Security, then Camera, and checking the box for whichever browser runs Meet.

Safari is a special case worth noting, because it keeps a second layer of its own. Apple's instruction for allowing a website to use the camera in Safari is to choose Safari, then Settings, then click Websites, then select Camera. Granting Safari access at the system level does not by itself grant a site access inside Safari.

The Chrome rule that kills video when you switch away

One symptom deserves its own explanation because it looks like a bug and is documented behaviour.

Chrome's documentation on camera and microphone use states that allowed sites can start to record when you are on the site, and that if you are using a different Chrome tab or a different app, a site cannot start recording. The restriction applies to starting a capture, not to one already running, which is why the effect is intermittent and hard to pin down.

In practice it produces this sequence. A meeting is joined, the camera works. The camera is turned off to look at a document in another tab. Turning it back on while that other tab is focused does nothing, because the request to start capturing arrives while Meet is in the background. Returning to the Meet tab and toggling again works, and the earlier failure looks random.

Two arrangements avoid it. The first is to make the browser prompt an explicit allow rather than a temporary one. Chrome offers Allow while visiting the site, Allow this time, or Never allow, and a past Never allow is sticky enough that the prompt never reappears. The second is structural: keep the call in a window of its own instead of as one tab in a pile, so that returning to it is a window switch rather than a hunt through tabs. Giving each web app a window of its own is the whole premise of an app aggregation browser, described on the Workspaces page.

Continuity Camera changes the camera list without warning

On a Mac paired with an iPhone, the list of available cameras is not stable, and a device that vanishes mid meeting is often an iPhone rather than a fault.

Apple's Continuity Camera documentation describes several ways a session pauses or ends. Unlocking the iPhone pauses it, and resuming requires locking and mounting the phone again, sometimes with a restart of video in the app. Answering a call on the Mac pauses the session, and afterwards the iPhone may have to be chosen again in the app. Tapping Disconnect on the iPhone, or carrying it out of Bluetooth range, pauses the session or switches to another camera if one is available, and removes the iPhone from the camera and microphone lists on the Mac.

That last clause explains a specific and confusing failure. Meet was using the iPhone, the phone left the desk, and the camera Meet had selected no longer exists. The fix is either to bring the phone back, mounted and locked, or to select the built in camera in Meet's settings.

Where an iPhone keeps being chosen without being wanted, the feature can be switched off from the phone: Settings, then General, then AirPlay & Continuity, then turn off Continuity Camera. Apple notes that this stops the Mac recognising the iPhone as a camera or microphone even when it is plugged in and mounted.

When the tile is not black but the video is bad

A working camera that produces unusable video belongs to a different set of causes, and it helps to recognise the boundary so the permission checks above are not repeated pointlessly.

Google Meet carries a built in diagnostic for this case. When a network or device issue is detected that may affect call quality, a red dot appears on the More options button, and opening Troubleshooting and help from that menu shows recommendations tailored to the detected issue. Two details make the dot easy to miss: it is shown for five minutes or until More options is clicked, and it appears only once a day even when the issue persists.

For quality problems specifically, Google's advice is concrete. Close non-essential tabs and other apps, reduce the size of the Meet window, disconnect external monitors, and prefer a wired connection or the 5 GHz band over the more heavily used 2.4 GHz. A VPN routes traffic through an extra location and can delay video, so turning it off temporarily is a fair test. On laptops that run hot, sending and receiving at standard definition, 360p, and switching to the Spotlight layout both reduce the load.

The dividing line is simple. No image at all points to permissions, another app holding the device, or a camera that no longer exists. A poor image points to bandwidth, layout, and how much else the machine is being asked to do at the same time.

The order to check, with a meeting already running

When a call is in progress, the sequence below moves from the cheapest check to the most disruptive, and each step rules out a layer.

Step	What it rules out	Where to look
Is the green light on next to the lens	Another app holding the camera	The camera housing
Does Photo Booth show a preview	Hardware and privacy covers	Photo Booth
Click the camera control in the address bar	The per site answer in this browser	Chrome address bar
Check Privacy & Security, then Camera	The system level block	System Settings
Check the camera chosen in Meet settings	A device that no longer exists	Meet settings, Video
Reload the Meet tab	A stale capture request	The tab itself

Chrome keeps the per site setting under Settings, then Privacy and security, then Site settings, then Camera, where an existing entry for a site can be deleted so the prompt returns, and a default camera can be chosen from the same screen. Google's page adds the detail that under Default behavior the option to select is Sites can ask to use your camera.

If none of the six steps changes anything, the last cheap move is to update the browser. Google lists browser updates among the first things to check for camera problems, and a browser that has not been relaunched in weeks may be sitting on a pending update.

What to change first

Turn on the habit of watching the green light. It converts the vaguest class of camera problem, where everything looks configured correctly, into a yes or no answer about whether another app is holding the device, and it costs nothing.

After that, look at how the call sits on screen. A meeting sharing a browser window with thirty tabs runs into the background tab rule, competes for memory, and makes switching back to the call slow at the moment it matters. Google's own guidance on overheating laptops points the same direction, advising against putting another window on top of a Meet window because the layering adds GPU load, and suggesting half screens instead. Keeping each web app in a window of its own is what SpaceDeck is built for, and the Supported apps page lists which services can be pinned that way.