How to Check That Audio Stays Local in Your Browser

Modern browsers show an icon near the address bar when a site has microphone permission or is actively using the microphone. Before recording, look for the permission prompt and read which site is asking. After the test, you can open the site-permission controls to see whether access remains allowed and revoke it whenever you choose.

Permission alone does not prove what a page does with audio, but it establishes a clear boundary: you are choosing whether the browser can provide the stream. A trustworthy product should explain why it asks, allow the core page to load without access, and never make unrelated features depend on a microphone grant.

On desktop Chrome, Edge, Safari, or Firefox, open developer tools and choose the Network panel. Clear the list, begin a test, speak, stop, and wait for the report. Filter for Fetch/XHR requests and look at request details. A local-only analyzer should not send an audio file, a long encoded data string, raw PCM frames, or a stream of acoustic measurements while you record.

Some normal requests can still appear, such as page assets, fonts, or a form provider after you voluntarily submit a waitlist email. Their existence is not evidence that audio is uploaded. The important check is whether recording activity creates requests carrying voice content or analysis data. It should not.

An email waitlist is a distinct action. It should not be needed to see a free local result, and the form should make clear what it sends. Enter only the information you wish to provide. The form should not attach audio, send the report automatically, or build a hidden profile from pitch and presentation values.

If you decide not to join a waitlist, you should still be able to record and analyse locally. This separation is useful not only for privacy but for clarity: a person should know when they are using an on-device tool and when they are choosing to contact a service.

Use up-to-date browsers, avoid recording private material on a shared device, and close the page when you finish. Review the site privacy policy for its claims about audio, cookies, forms, and future advertising. If a policy changes materially, decide whether you are still comfortable using the service before recording again.

No web check can substitute for reading a policy and making an informed choice, but permission indicators and developer tools give you a concrete way to test the most important promise. Local analysis should leave the recording on your device rather than turning it into a hidden upload.

A Network check is especially valuable after a site update. Open the browser’s developer tools in a fresh session, preserve the log, and perform the exact actions a normal visitor would: load the page, grant microphone access, record, stop, view results, and decline or submit an optional form. Inspect the requests triggered at each point. This distinguishes normal page assets from the sensitive path that must remain local.

If you find a request that is unclear, do not assume it is harmless or malicious from its name alone. Inspect its method, headers, and request payload, then compare it with the privacy policy. An operator should be able to explain every request. A visitor can decide not to record until the explanation is satisfactory. Transparency is stronger when it can be tested this way.