How browser-local transcription handles your audio

Follow the data through the actual workflow

A useful privacy explanation starts with the path the data takes. In MurmurScribe, selecting a file gives the page access to that local file. The browser decodes the audio, prepares the model input and sends that sample array to a Web Worker in the same browser. The worker runs inference locally and returns transcript segments to the page.

There is no audio-upload API in this workflow. Filenames and transcript text are not sent to analytics. That is a narrower and more useful statement than saying that nothing ever leaves the device during any use of the website. Loading a page and downloading software still involve network traffic.

The model download is separate from the recording

Whisper weights and configuration files come from Hugging Face and its delivery infrastructure. Supporting runtime files may come from a software CDN. The providers see ordinary request information such as an IP address and the software file being requested. The recording is not included in those requests.

The first model run may involve a substantial download. Later runs can use browser-cached files if they remain available. A source page should disclose this rather than presenting a download spinner as if an audio upload were taking place. The app’s status messages distinguish model loading from local transcription.

A worker keeps computation off the main interface

A Web Worker runs work separately from the page’s main JavaScript execution context. This helps keep controls responsive while speech recognition is running. It is still local browser computation. A worker is not the same as a remote server, despite the similar word used in some hosting products.

Cancellation terminates the inference worker. The UI can therefore stop a long run without waiting for the model to finish the entire recording. That control is useful when a device is struggling or the wrong file was selected. It does not recover work that has not been returned, and it does not undo an export already downloaded by the user.

Local storage has its own privacy questions

IndexedDB stores recordings and edited transcripts in the browser profile when available. This makes it possible to reopen local work, but it is not a separate encrypted vault managed by the product. Someone with access to the profile or device may have access to its stored data.

Browser storage is also subject to availability and eviction rules. Private browsing, cleanup settings and storage pressure can remove work. A local save message should not be interpreted as a durable backup guarantee. Export important transcripts to a location you manage, then protect that location according to the sensitivity of the material.

Shared devices need particular care. No account is required here, but that does not mean one person’s browser session is isolated from another person using the same profile. Delete local work when it should not remain accessible and check device-level arrangements separately.

Deletion applies to specific copies

The delete-all control clears the app’s IndexedDB recordings and the Transformers model cache. It does not reach into folders where you downloaded a DOCX or subtitle file. It cannot remove copies sent to a colleague, stored in a backup or uploaded to another publishing system.

This distinction is easy to miss when a workflow spans several tools. Make a simple inventory of the copies you intentionally created: source recording, browser-local copy, reviewed export and shared delivery. Delete or retain each according to the purpose. A single button on a website cannot manage the entire lifecycle outside its own storage.

If browser storage is unavailable or full, the app reports that condition and directs you to export. Treat the visible save status as part of the workflow rather than assuming that every edit has been kept indefinitely.

Private processing is not an institutional approval

Local inference can be valuable for sensitive work, but it does not establish that a tool is approved by an employer, research protocol or professional setting. Permission to record, rules about access and requirements for recordkeeping remain separate questions. MurmurScribe does not claim a compliance certification or provide a clinical or legal records system.

The optional Pro waitlist is another distinct data path. It sends an email address to the site’s server so availability updates can be provided. It does not send a recording or transcript. Joining that list is not required to use the current app.

Choose a workflow based on the actual data path and the responsibility you retain. If a team needs managed access, audit history or formal retention controls, an individual browser workspace may not be sufficient even though its audio processing is local.

Worked example

Imagine an authorized interview file on your laptop. You select it, download Tiny, review the resulting transcript and save a DOCX to a project folder. There are now distinct copies to manage: the original file, any browser-local saved recording, and the exported document. Clearing local app data removes the browser copy and cached model, while the original and DOCX remain. If you later email the DOCX, that creates another data path outside MurmurScribe. The local inference claim remains true, but it does not describe every later action you take with the output.

Open the local transcriber to test an authorized recording and review the draft against the sound.

Verify the claim at the right boundary

A privacy claim should be testable at the boundary it describes. For local transcription, the relevant question is whether file contents or transcript text are sent to a remote service during the flow. Ordinary requests for the page, fonts and model files are a different category and should be disclosed rather than hidden behind an absolute slogan.

A developer can inspect requests while selecting a test recording, running inference, editing text and exporting. That observation should use non-sensitive material and check both the destination and request body. A clean result for one version is evidence about that version, not a permanent guarantee about every future change. Features that add new network requests need another review.

Users can also make practical distinctions without reading code. A tool that requires an account upload, a connected cloud folder or a meeting bot has a different data path from selecting a file for local computation. Neither path is automatically appropriate for every situation. The choice depends on the content, permissions and controls required for the job.

Keep product descriptions specific when sharing the workflow with a team. Say that this app processes selected audio locally and describe the local storage and model downloads. Do not turn that into a claim that the device is secure, the browser is isolated from other users, or a particular organizational standard is satisfied. Accurate boundaries make the privacy benefit easier to assess and prevent a useful technical property from being mistaken for a broader assurance.