Why sandboxed frames cannot access a microphone

A microphone works on a webpage but not inside an embedded frame. Or the browser never shows a permission prompt when an app inside a frame tries to start recording. This often happens because the frame has not been granted microphone access, not because the microphone is broken.

Check the browser and microphone separately, then look at the rules on the embedded frame and the page that contains it. That will help you identify whether the problem is a browser permission, an operating system setting, or the way the site embeds the app.

Check microphone access in and out of the frame

1. Open Browser Info and review the browser version, privacy details, permissions, and supported features. This gives you a baseline, but it does not inspect a specific iframe's settings.
2. Open the same app or site directly in a new tab, outside the embedded frame. If you can, test the microphone there with the Microphone Test. Press Start microphone, allow access when asked, and speak to see whether the signal meter moves.
3. Try the embedded version again and note what happens. A permission prompt, a denial message, or no response at all can point to different causes.
4. If you manage the site, inspect the iframe element and the page's response headers. Look for its sandbox and allow attributes, as well as any microphone policy set by the server.

A microphone test in a separate tab is useful for comparison, but it does not prove that the embedded frame is allowed to use the microphone. The browser checks the permissions and security rules for the frame as well as the user's microphone permission.

What the result means

The microphone works in a tab but not in the frame

The microphone and browser can work, while the embedded context is blocked. The frame may not have been given microphone permission, the containing page may have a policy that blocks it, or the sandbox may give the frame a restricted origin. If you are just visiting the site, its owner may need to change the embed. If you manage it, check the frame and response header.

The microphone is blocked in both places

Check the browser's permission for the site and the operating system's microphone access setting. Also check whether the browser is using the expected input device. A blocked permission in the standalone tab makes an iframe-specific rule less likely to be the only cause.

No permission prompt appears in the frame

A prompt may not appear if the frame is not allowed to request microphone access in the first place. A browser can reject the request before asking you. This is common when microphone access has not been delegated to the frame or a policy blocks it.

The frame works in one browser but not another

Browsers can differ in how they report denied permissions and support web features. Check the browser version and permissions in Browser Info, then compare the result in a current browser that supports microphone access. A different result is a useful clue, not proof that the browser is at fault.

How to fix it

1. Allow microphone access for the site. Open the site in a normal tab, use the site information or permissions control beside the address bar, and set microphone access to allow. Reload the page. Browser labels and menus vary, and allowing the top-level site may not override a frame policy.
2. Check system microphone privacy. On Windows 11, open Settings › Privacy & security › Microphone and turn on microphone access and access for desktop apps. On macOS, open System Settings › Privacy & Security › Microphone and enable access for the browser. Then reload the page and try again.
3. Close other apps using the microphone. Quit calling or recording apps, then retry. This is more likely to help if the browser reports that the microphone is in use, rather than if only the embedded frame is blocked.
4. Make sure the page uses HTTPS. Microphone capture normally requires a secure context. If you are developing locally, use a supported local development address; for a public site, serve it over HTTPS.
5. Delegate microphone access to the frame. If you control the embedding page, its iframe needs an allow='microphone' attribute, and the containing page's Permissions-Policy response header must permit the frame's origin. A header that denies microphone access can block the request even when the iframe has an allow attribute.
6. Review the sandbox restrictions carefully. A sandboxed frame may have a restricted, opaque origin unless it receives the allow-same-origin sandbox token. Some microphone permission flows require a recognizable origin. Add permissions only when the embedded content is trusted: allow-same-origin relaxes an important sandbox boundary, and it is not itself a microphone permission. The frame still needs the appropriate microphone delegation and the user's approval.

For nested frames, each level of the embedding chain must permit the feature. If you do not control the site's code or server headers, you cannot safely fix those rules from your browser settings. Send the site owner the browser name, the frame URL, and whether the microphone works when opened directly.

Why sandboxing changes the request

An iframe is a webpage placed inside another webpage. The sandbox attribute limits what that embedded page can do, such as running scripts, navigating, or accessing its normal origin. These limits help protect visitors from untrusted content.

Microphone access is also controlled by the browser's permission system and by Permissions Policy. The frame must be eligible to request the microphone, the parent page must allow it, and the visitor must grant permission. These are separate checks. Adding allow='microphone' delegates the feature; it does not silently grant permission or override a browser or operating system block.

The Microphone Test requests permission before using the microphone. Its short recording stays on your device, and nothing you record is uploaded.