Every modern browser handles webcam and microphone permissions differently. The menus keep moving — Chrome reorganised its site settings in 2024, Safari 17 changed the per-site flow on macOS, and Manifest V3 quietly shifted how embedded iframes can request camera access. Most guides cover Chrome, wave at Firefox, and call it a day. This one covers all six browsers you actually encounter in 2026: Chrome on desktop and Android, Safari on macOS and iOS, Firefox, Edge, and Brave. Bookmark it, skip to your browser, fix the permission, then verify it worked.

TL;DR — where each browser stores cam/mic permissions

  • Chrome (desktop): chrome://settings/content/camera and chrome://settings/content/microphone — or click the lock icon in the address bar for per-site control.
  • Chrome (Android): Three-dot menu → Settings → Site settings → Camera / Microphone.
  • Safari (macOS): Safari → Settings → Websites → Camera / Microphone. Safari 17+ shows a per-site dropdown.
  • Safari (iOS/iPadOS): Settings app → Apps → Safari → Camera / Microphone / Location.
  • Firefox: about:preferences#privacy → Permissions section → Camera / Microphone → Settings.
  • Edge: edge://settings/content/camera and edge://settings/content/microphone — identical flow to Chrome.
  • Brave: brave://settings/content/camera — plus check Brave Shields, which can block getUserMedia calls independently of the permission grant.

After changing any of these, open clipy.online/mic-webcam-test in the same browser to confirm the camera and mic are live before you jump back into your meeting or recording session.

How browser permissions actually work

getUserMedia and secure origins

Every browser routes webcam and microphone access through the getUserMedia API. Browsers only honour it on a secure origin — https://, localhost, or file:// in some cases. Plain http:// sites will never show the permission prompt; the API errors silently. This catches people who self-host tools on internal HTTP addresses.

Persistent vs. one-shot grants

When the permission popup appears, most browsers give you two options: allow once (for this session only) or allow permanently (remember for this site). If you chose allow once last time, the popup comes back next visit — that is working as intended, not a bug. Chrome labels the persistent option Allow and the session option is implicit if you dismiss via the address-bar icon. Firefox explicitly shows a Remember this decision checkbox. Safari on iOS has no persistent-allow option for camera; it will always ask again next session. More on that in the Safari section.

The OS layer sits above the browser layer

Both macOS and iOS/Android have a system-level camera toggle that overrides browser settings. If Chrome shows Allowed but the camera still does not work, check System Settings → Privacy and Security → Camera on macOS (or Settings → Privacy → Camera on iOS). A browser cannot grant what the OS has denied.

Third-party iframes

Embedded tools — a Loom player inside Notion, a Google Meet widget, or a recording tool like Clipy loaded inside an iframe — cannot ask for camera permission on behalf of the parent page unless the parent explicitly opts in via a Permissions-Policy header or an allow="camera; microphone" attribute on the iframe tag. This is the reason some embedded recorders work fine standalone but seem broken when embedded. We cover this properly in the third-party iframes section below.

Chrome (desktop) — the full walkthrough

Chrome is the most granular of the major browsers for camera and microphone control, which is both useful and occasionally confusing because the setting lives in three different places depending on what you are trying to do.

The global default

Go to chrome://settings/content/camera (or chrome://settings/content/microphone for the mic). At the top you will see a toggle between Sites can ask to use your camera and Do not allow sites to use your camera. The first option is what you want for normal use — it means Chrome will show the popup and let you decide per site. The second option blocks all requests silently, which is why some users never see a permission popup and just get a black screen.

Per-site overrides

Scroll down on the same settings page and you will find two lists: Allowed to use your camera and Not allowed to use your camera. If a site lands in the wrong list, click the arrow next to its URL to flip it. You can also delete the entry entirely, which forces Chrome to ask again on the next visit.

The fastest per-site shortcut: click the lock icon (or the tune icon in newer Chrome versions) in the address bar while you are on the site. A small popup shows Camera and Microphone dropdowns set to Ask, Allow, or Block. Changing it here is instant — no need to dig through settings.

Why the popup keeps appearing

If you are being asked every visit, you likely chose Allow for this visit or dismissed the popup without making a choice. Chrome treats a dismissed popup as a temporary block. Next visit it asks again. To stop the cycle, visit the site, click the address-bar lock, and explicitly set Camera to Allow.

What changed in 2025–2026

Chrome 120+ moved the per-site permission indicator from a lock icon to a tune/sliders icon for sites using HTTPS. The lock is still there for HTTP sites. The underlying settings paths (chrome://settings/content/camera) have not changed, but the visual trigger in the address bar looks different — which is why older guides show screenshots that no longer match.

Chrome (Android) — site settings path

On Android, Chrome camera permission has two layers: the browser per-site setting and the Android OS app permission. You need both to be allowed for a site to see your camera.

Browser-level

Open Chrome → tap the three-dot menu → Settings → Site settings → Camera (or Microphone). You will see the same global toggle and a list of per-site overrides as desktop Chrome. Find the site that is failing, tap it, and switch from Block to Allow.

OS-level

If Chrome itself does not have camera permission on Android, no site can use it. Go to Android Settings → Apps → Chrome → Permissions → Camera and confirm it is not set to Do not allow. The exact path varies by Android version and skin, but the destination is the same.

Once both layers are green, test with the mic and webcam test before joining your call.

Safari (macOS) — Settings → Websites

Safari handles permissions differently from the Chromium browsers. There is no URL you can type into the address bar to reach a global camera settings page. Instead, it lives in the application menu.

Finding the setting

Open Safari → click Safari in the menu bar → Settings (or Preferences on older macOS) → click the Websites tab → scroll the left sidebar to find Camera or Microphone.

The right pane lists every site Safari has been asked about. Next to each site is a dropdown: Allow, Deny, or Ask. Set it to Allow and the popup will not come back. Set it to Ask and Safari will ask each visit. There is no allow once option here — Ask is the closest equivalent.

Safari 17+ changes (macOS Sonoma and later)

Safari 17 (shipped with macOS Sonoma in late 2023, updated through 2024–2025) introduced a refreshed Websites settings panel. The per-site dropdowns are still there, but the UI chrome changed: camera and microphone are now grouped under a Privacy subsection of the Websites tab on some builds. If you cannot find Camera in the sidebar, look for a Privacy section first. The permission logic itself is unchanged.

The address-bar shortcut

While on a site, click the Website Settings icon (the two A’s / aA icon) on the left side of Safari address bar. A small panel opens with Camera and Microphone dropdowns. This is faster than going through the menu for a one-off fix.

macOS system permission

Safari needs macOS camera permission too. Go to System Settings → Privacy and Security → Camera and confirm Safari is ticked. If it is not listed at all, Safari has not asked yet — load a site that requests camera access and the OS prompt will appear.

Safari (iOS/iPadOS) — Settings app, not in Safari itself

On iPhone and iPad, Safari camera and microphone permissions are managed from the iOS Settings app, not from inside Safari. This trips up almost everyone.

Finding the setting

Open Settings (the grey gear icon) → scroll down and tap Apps → tap Safari → scroll to the Settings for Websites section → tap Camera or Microphone.

You have three options: Ask, Deny, and Allow. Apple default is Ask, which means a prompt appears every single time any site requests camera access. There is no per-site persistent Allow the way Chrome has it — iOS Safari will re-ask per session for most sites regardless of this setting. Setting it to Allow globally means Safari will grant camera access without prompting, which is the only way to stop the popup cycle on iOS.

Why Safari requires a user gesture

iOS WebKit enforces a rule that getUserMedia() can only be called from inside a user-gesture handler — a tap or click event. Pages that try to auto-start the camera on load will fail silently on Safari/iOS even if permissions are fully granted. If a web-based recorder seems frozen on iOS, make sure you are tapping a specific Start or Allow button, not expecting the camera to start automatically.

Per-site overrides on iOS

iOS 16+ added per-site camera controls accessible from Safari address bar. While on a site, tap the aA icon → Website Settings → toggle Camera and Microphone. Changes here override the global Settings app values for that one site.

Firefox — about:preferences#privacy

Firefox has one of the most transparent permission systems of any browser. It gives you a visible exception list you can edit directly, and it explicitly asks whether to remember your decision each time the prompt appears.

Finding the setting

Type about:preferences#privacy in the address bar and press Enter. Scroll down to the Permissions section. You will see entries for Camera, Microphone, Location, Notifications, and more. Each has a Settings… button that opens a dialog listing every site you have granted or blocked.

In the dialog, find the site you want to change, click the dropdown next to it, and switch between Allow and Block. Click Save Changes. The change takes effect on the next page load.

The Remember this decision checkbox

When Firefox shows the permission popup, there is a Remember this decision checkbox at the bottom. If you clicked Allow or Block without ticking that box, Firefox treated your choice as one-session-only and will ask again next visit. That checkbox is the most commonly missed step in Firefox permission troubleshooting. If the popup keeps returning, check the preferences page — the site probably has no saved exception at all.

Private Browsing

In Firefox Private Browsing windows, permission exceptions are not stored between sessions. Every private window starts with a blank permission slate. This is expected behaviour and not a bug. If you always use private windows and need camera access, you will need to grant it each session — or switch to a regular window for recording work.

What changed in 2025

Firefox 120+ introduced a permission auto-deny cooldown: if a user dismisses the popup three times without choosing, Firefox blocks the request automatically for the session and shows a small notification. The block resets on the next visit, but while it is active the only way to unblock it is through about:preferences#privacy.

Edge — edge://settings/content/camera

Microsoft Edge is built on Chromium, so its camera and microphone permission system is nearly identical to Chrome. If you know Chrome settings paths, you know Edge.

Finding the setting

Type edge://settings/content/camera or edge://settings/content/microphone in the address bar. You will see the same global toggle (ask vs. block) and the same per-site allow/block lists as Chrome. The address-bar lock icon also provides a per-site dropdown — look for the Permissions for this site entry in the dropdown.

Edge-specific wrinkle: Enhanced Security Mode

Edge Enhanced Security Mode (sometimes called Super Duper Secure Mode in early builds) can interfere with WebRTC camera access on sites it classifies as not frequent. If camera access is blocked on a site that should work, check Settings → Privacy, search and services → Enhanced Security Mode and add the site to the exceptions list, or disable the mode entirely for testing.

Work and school accounts

If Edge is signed into a Microsoft 365 work account, an IT admin policy may override camera permissions and grey out the settings. Contact your IT department in that case.

Brave — brave://settings/content/camera plus Shields

Brave adds a layer that Chrome and Edge do not have: Brave Shields. Even if the browser-level camera permission is granted, Shields can block the WebRTC request that getUserMedia makes. This is the gotcha unique to Brave and the first thing to check if permissions look correct but the camera still does not work.

Browser-level permission

Type brave://settings/content/camera or brave://settings/content/microphone. The UI is identical to Chrome. Set the global default, check the per-site lists, and flip anything in the wrong bucket.

Brave Shields

While on the site that needs camera access, click the Brave Shield icon (the lion head) in the address bar. You will see a panel with Trackers and Ads, Cross-site cookies, and — critically — Fingerprinting blocked. getUserMedia device enumeration can be treated as a fingerprinting vector, so Brave aggressive fingerprint blocking can prevent the camera from initialising even after the permission is granted.

Try switching Fingerprinting protection from Strict to Standard or temporarily toggling Shields off for the site. If the camera starts working immediately, fingerprint blocking was the culprit. Add the site to Brave per-site Shields exceptions to keep protection on everywhere else while allowing camera access on that site.

WebRTC IP handling

Brave also exposes a WebRTC IP handling policy at brave://settings/privacy. If it is set to Disable non-proxied UDP, getUserMedia calls can fail. Keep it at Default for normal camera use.

The permissions keep being asked every visit problem

It almost always comes down to one of five root causes.

  • You chose allow once or dismissed the popup. In Chrome, clicking away from the popup without choosing is logged as a dismissal and treated as a temporary block. In Firefox, granting without ticking Remember this decision has the same effect. Fix: revisit the site, grant the permission, and make sure you are choosing the persistent allow — not just dismissing.
  • You are using a private/incognito window. Incognito and Private Browsing windows do not persist permissions across sessions. The popup will appear every single time. This is intentional privacy behaviour. Use a regular window if you need persistent camera access.
  • The site is on HTTP, not HTTPS. Browsers block getUserMedia on insecure origins entirely. The popup cannot even appear. The site URL needs to start with https://.
  • A browser extension is interfering. Privacy Badger, uBlock Origin in some configurations, and some VPN extensions intercept WebRTC calls. Disable extensions one by one in a test profile to narrow it down.
  • Safari on iOS has no persistent per-site grant. Apple WebKit on iOS always re-asks for camera permission per session for security reasons. Setting the global Safari Camera permission to Allow in Settings stops the popup — it does not give individual sites a persistent grant, but it removes the need to confirm each time.

Once you have fixed the root cause, use the camera and microphone test to confirm everything is working before your next call or recording session.

Third-party iframes — why some embedded tools cannot ask for camera access

If a browser-based recorder embedded in Notion or Confluence silently fails to access the camera — here is why, and what can actually be done.

How iframe permissions work

When an iframe loads a third-party page, the browser applies Permissions Policy to decide whether the iframe can even request camera access. By default, browsers block camera and microphone in cross-origin iframes — the parent page must explicitly opt in.

The opt-in can happen two ways. First, the parent page server can send a Permissions-Policy: camera=(self "https://example.com") HTTP header listing the embedded origin. Second, the iframe tag itself can carry an allow="camera; microphone" attribute. If neither exists, the camera request fails silently inside the iframe regardless of what the user has granted to either origin individually.

The Loom-on-Notion example

This is exactly what happens when someone embeds a camera-based tool inside Notion. Notion server does not send a permissive Permissions-Policy header for third-party camera origins, and Notion embed blocks do not inject allow="camera" into the iframe. So even if the user has granted the embedded tool camera access in a standalone tab, it fails inside the Notion embed.

The fix has to happen at the parent page level. If you control the parent page, add allow="camera; microphone" to the iframe tag. If you do not control it (Notion, Confluence Cloud, etc.), the embedded tool simply cannot use the camera — open it in a dedicated tab instead.

Manifest V3 and permission changes

Chrome Manifest V3 (fully rolled out through 2024) changed how extensions interact with permissions but did not alter how getUserMedia works on first-party pages. The practical change: MV3 extensions can no longer silently intercept camera streams via content scripts. Normal site camera requests are unaffected.

After changing settings, verify with the mic and webcam test

Do not assume the change worked — browser permission changes can have a one-reload lag, and the OS layer may still be blocking. The fastest check is a live test.

Open clipy.online/mic-webcam-test in the browser you just changed. The page will request camera and microphone access using the same getUserMedia call that any recording tool uses. If the camera feed appears and the microphone level bar moves when you speak, both permissions are fully working end to end — browser layer and OS layer.

If you want to test them separately, the webcam test and the microphone test are available as standalone pages. Testing separately is useful if you need to confirm whether a problem is camera-specific or microphone-specific before spending time in settings.

Both tools are completely free, run in the browser, and do not require an account. The camera feed stays local — nothing is uploaded. See the broader webcam and mic test guide for a full walkthrough of what the test results mean.

If permissions are correctly granted but the camera still shows a black screen, a frozen feed, or an error code, the problem may be at the hardware or driver level rather than the permissions layer. A full diagnosis for Chrome specifically is in webcam not working in Chrome — full fix guide. The most common hardware-layer culprits are another application holding an exclusive camera lock (Zoom, Teams, FaceTime, or OBS running in the background) and outdated drivers on Windows.

If the camera works in the camera and microphone test but fails only inside a specific web app, the culprit is almost always the third-party iframe permissions problem described above.

FAQ

Why does private/incognito mode reset permissions every session?

Private windows leave no persistent state on your device by design — storing permission grants would let sites fingerprint your private-window identity. Every incognito session starts clean. Use a regular window if you need persistent camera access.

Can I grant camera access without granting microphone access, or vice versa?

Yes, on most browsers. Chrome, Edge, Brave, and Firefox all treat camera and microphone as separate permissions — you will see separate prompts (or separate dropdowns in the settings) and can allow one while blocking the other. Safari on macOS also separates them in the Websites settings panel. Safari on iOS gives you separate toggles in Settings → Apps → Safari → Camera and Microphone. The only case where they are coupled is when a web app calls getUserMedia with both video and audio in a single prompt — but even then, the browser stores the grants separately and you can revoke one without revoking the other via settings.

Why is Safari more strict about permissions than Chrome?

It is a deliberate WebKit policy choice, not a technical limitation. Apple treats camera/mic as high-sensitivity capabilities requiring repeated explicit consent. iOS Safari is the strictest: no auto-start, user gesture always required. macOS Safari supports persistent per-site grants but defaults to Ask. If you build tools that need camera access, test on Safari separately — the behaviour genuinely differs from Chrome.

Does revoking camera access in macOS System Settings override the browser allow setting?

Yes, always. The OS layer sits above the browser layer. If you revoke camera access for Chrome (or Safari, or Firefox) in macOS System Settings → Privacy and Security → Camera, no website in that browser can access the camera regardless of what the browser own per-site settings say. The browser can only grant what the OS permits it to grant. After re-enabling in System Settings, you may also need to restart the browser for the change to take effect — some browsers cache the OS permission state at startup.

Why does a page refresh not fix the permission denied popup?

A refresh re-runs the JavaScript, which calls getUserMedia again — but it does not change the stored permission state. If the permission is Block, the API throws a NotAllowedError on every call regardless. Change the permission in settings or the address-bar dropdown, then reload. That reload is what forces browsers to re-evaluate the stored state.

Bottom line

Browser camera and microphone permissions are not complicated — they just live in different places depending on which browser you are in, and the locations move with major browser updates. The rules are consistent: HTTPS required, OS permission above browser permission, persistent grants require an explicit remember step, and iframes need parent-page opt-in. Once you know those four rules, every browser settings page makes sense even if the path changed since the last guide you read.

If you are troubleshooting right now: find your browser settings path in the sections above, flip the relevant site from Block or Ask to Allow, then confirm it is working at clipy.online/mic-webcam-test. Two minutes, no guessing.

And if you need a recorder that works cleanly in the browser once permissions are sorted — no account, no watermark, no install required beyond a Chrome extension — Clipy is free and ready whenever you are.