Camera Not Found in Google Meet: What the Browser Actually Sees

Google Meet reports two camera problems with two different phrases, and treating them as the same message sends the search in the wrong direction. Camera failed means something was there and could not be opened. Camera not found means the browser asked the operating system for a video device and got an empty answer back.

The second case is the stranger one, because the camera is usually right there above the screen and works in Photo Booth. Understanding what a browser is actually permitted to see, and when that view changes, turns the error from a mystery into a short list of causes.

The two messages are not interchangeable

The web platform behind Meet defines separate errors for separate situations, and the wording in Meet tracks them closely enough to be useful.

When a page asks for a camera, the request is rejected with one of a handful of named errors. MDN's reference for getUserMedia lists them: NotFoundError is thrown when no media tracks of the type specified were found that satisfy the given constraints, while NotReadableError is thrown when permission was granted but a hardware error occurred at the operating system, browser or page level that prevented access. A third, NotAllowedError, covers a denied permission, and a fourth, OverconstrainedError, covers constraints that no available device could meet.

Mapping that onto what appears on screen gives a usable split.

What Meet says	What it usually means	Where to look first
Camera not found, no camera found	The device list came back without a camera	The camera list on the Mac
Camera failed	A camera exists but could not be opened	Permissions, or another app holding it
Black tile, no error text	A permission was answered no at some point	Browser site settings

Google's own troubleshooting page supports the middle row directly, noting that the Camera failed error often means the browser cannot access the camera. The top row is the one worth digging into, because an empty list has causes that have nothing to do with permissions.

What a browser is allowed to see before permission

A browser does not get a plain view of the hardware. The device list it reads is filtered, and the filtering explains several confusing behaviours.

MDN's page on enumerateDevices sets out the constraints. The method has to be called in a secure context, meaning HTTPS. The document has to be fully active and its visibility has to be visible. The returned list omits devices blocked by the document's permission policy for camera or microphone. And other than default capture devices, only devices for which permission has been granted are treated as available, with default devices listed first.

The effect on names is visible in MDN's own example output. Before permission is granted, the entries carry opaque identifiers and no readable label at all. Once a stream is active or a persistent permission exists, the same entry reads as something like FaceTime HD Camera, built in.

Three practical consequences follow.

• A page served over plain HTTP gets nothing, by design. This bites on internal tools and old bookmarks rather than on meet.google.com itself.
• A camera picker that shows blank or numeric entries is not broken. It is showing an unpermissioned list, and granting access once fills in the names.
• A tab that is not visible is in a weaker position than a tab in front. The visibility requirement is part of the specification, not a browser quirk.

That last point lines up with a documented Chrome rule. Chrome's guidance on camera and microphone use states that an allowed site can start recording while you are on the site, and that a site cannot start recording while you are in a different Chrome tab or a different app. A camera that refuses to come back on while a document is being read in another tab is following that rule.

A Mac's camera list is not a fixed list

The assumption behind most advice on this error is that a computer has one camera and it is either present or absent. On a modern Mac, the list changes during the day without anyone changing a setting.

Continuity Camera is the largest source of movement. Apple's documentation describes a session pausing when the iPhone is unlocked, pausing when a call is answered on the Mac, and pausing or switching to another camera when Disconnect is tapped on the phone or the phone moves out of Bluetooth range. That last case has an explicit consequence: the iPhone is removed from the camera and microphone lists on the Mac. If Meet had selected the iPhone, the selected device no longer exists and the error arrives without anything on the Mac having been touched.

Apple also notes that a mounted iPhone should be in landscape orientation to allow apps to choose it automatically, which is how a phone becomes the selected camera without a deliberate choice in the first place.

Other things reshape the list too. External webcams on a hub disappear when the hub is unplugged or renegotiates. Virtual camera utilities insert an entry that some browsers pick as default. Docking and undocking can change which device the operating system considers default, and default devices are listed first, which is what Meet tends to select.

To stop an iPhone being offered at all, the switch is on the phone: Settings, then General, then AirPlay & Continuity, then turn off Continuity Camera. Apple states this prevents the Mac from recognising the iPhone as a camera or microphone even when it is plugged in and mounted.

Checking the layers in order

When the list really is empty, the checks below move outward from the hardware and each one eliminates a layer.

Start outside the browser. Open the built in Camera app or Photo Booth and look at the self preview. Google's troubleshooting page uses this as the dividing test: if the preview shows an image and Meet does not, the hardware is fine and a permission is at fault. If the preview shows nothing either, check for a physical camera cover or a privacy switch, which sits above the lens on some laptops and on the side of others, sometimes with an orange, red or amber light when engaged.

Then check the system layer. Google's instruction for Macs is to go to System Settings, then Privacy & Security, then Camera, and check the box for the app that runs Meet, whether that is Chrome, Firefox, Safari or Edge, on macOS Mojave, version 10.14, or later. Apple adds a detail that causes needless searching: the list shows only apps that have been installed and have asked to use the camera, so a browser that has never requested access will not be listed, and an empty list is not proof of a block.

Then the browser layer. In Chrome, the per site permission lives under Settings, then Privacy and security, then Site settings, then Camera. Google's page describes selecting Sites can ask to use your camera under Default behavior, and deleting an existing entry for a site so that the prompt returns. Chrome's prompt itself offers Allow while visiting the site, Allow this time, or Never allow, and an earlier Never allow is sticky: the prompt stops appearing and the call quietly has no video.

Safari keeps a second gate of its own. Apple's instruction for allowing a website to use the camera in Safari is to choose Safari, then Settings, then Websites, then Camera. Granting Safari system access does not grant a site access inside Safari.

Finally, the tab. Reloading Meet after any of the above is not superstition. A page that was refused a device on load may not retry until it is reloaded.

When the camera exists but nothing matches the request

There is a fourth outcome that looks like not found and has a different cause, and it is worth recognising because no amount of permission fiddling resolves it.

A page does not simply ask for a camera. It asks for a camera meeting constraints, such as a minimum resolution or a particular facing direction. MDN notes that if the specified constraints result in no candidate devices meeting the criteria requested, the request is rejected with OverconstrainedError, and that this can happen before the user has granted permission at all. The error carries the name of the constraint that could not be met.

In everyday terms, this is the case where a camera is present and permitted but cannot produce what was asked for. An old external webcam limited to a low resolution, a virtual camera that reports capabilities it does not have, or a device already streaming at a fixed format to another app can all land here.

External hardware makes it more likely. A webcam behind a hub or dock can be renegotiated when another device is plugged in, and the operating system's notion of the default device can change with it, which matters because default capture devices are listed first and are the ones an application tends to select. Unplugging the hub and connecting the camera directly is a fast way to test whether the hub is the variable.

The fix in this class of problem is not a permission but a selection. Choose a device explicitly rather than accepting the default, and prefer the built in camera when a call has to start in the next minute.

Choosing the camera, rather than hoping

Once names are visible, picking a device deliberately prevents the error from returning at the worst moment.

Chrome allows a default camera to be set from the same Site settings screen, by opening Camera under Permissions and using the dropdown to select or switch devices. Setting this to the built in camera rather than leaving it on whatever is default removes a whole class of surprise, because the built in camera is the one device that does not walk away from the desk.

Inside a meeting, Meet keeps its own camera selection in settings, and it is the setting to correct when a device has vanished mid call. Choosing the built in camera there restores video without leaving the meeting.

For anyone who joins calls all day, one more arrangement is worth making. A call in its own window rather than one tab among thirty is both visible, which the specification requires for device enumeration, and quick to return to when the camera has to be toggled. Google's guidance on laptops running hot points the same way, 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 a tool such as SpaceDeck is built for, and the Features page sets out how that separation works in practice.

What to change first

Read the exact wording of the error before changing anything. Not found and failed point at different layers, and the two minutes spent reading the message saves the ten minutes spent on the wrong one.

After that, pin the camera down instead of leaving it to defaults. Select the built in camera explicitly in both the browser's site settings and Meet's own settings, and turn off Continuity Camera if an iPhone keeps being chosen without being wanted. The list of services that can be kept in separate windows, so that a call is never buried behind a wall of tabs, is on the Supported apps page.