Audio to MIDI privacy: the recording never leaves the tab.

The browser already keeps a log of every resource a page requests, so the test needs no packet capture. We loaded the converter, emptied that log, then walked through a full conversion — select a 16.48 MB WAV, press convert, wait for the finished state — and read the log again after each step. Anything the page sent would have to appear in it.

Six requests happen while the page loads, all of them for the page itself. After that the log stays empty for the rest of the session, including the moment a 16.48 MB file is handed to the input and the seconds in which it is analyzed. There is no request to inspect for size, no partial upload, and no second call at the end to fetch the result.

The output side is the more convincing half. The download link does not point at a file on a server; it points at blob:https://localmidi.com/<uuid>, an object the tab created. Its size tracks the notes it contains: a 20-second test file produced 35 notes and a 341-byte MIDI, and a 60-second file produced 106 notes and a 980-byte MIDI. A file that grows with the note count and is served from a blob address was written by the page, not fetched from somewhere else.

Test conditions. Chrome 154.0.8037.57 on Windows 11, the live converter at https://localmidi.com/audio-to-midi/. The browser ran on a dedicated profile with no extensions enabled, system proxy off and no PAC file, and DevTools closed — the log was read through the browser's debugging protocol, not the DevTools Network panel, so the panel's Disable cache option was never on. The request log is the browser's own performance timeline: it was cleared with performance.clearResourceTimings() after load, and read with performance.getEntriesByType('resource') after the file was selected and again when the status line reported the draft was ready. Files were uncompressed WAV, 44.1 kHz or 48 kHz, mono or stereo. The MIDI byte counts come from reading the blob URL back into an array buffer.

Two of the six load requests are not the page's own files: a script from static.cloudflareinsights.com and a ping to /cdn-cgi/rum on this domain. That is Cloudflare's analytics beacon, and it fires when the page loads — before any file has been chosen, at a moment when the page has nothing to send but the fact that someone opened it.

This matters for an honest answer rather than a comfortable one. The site does collect a page view, the same way it would for any visitor who never touches the converter. What it cannot do is attach your recording to that ping: the beacon fires during page load, before a file has been chosen, and the log is empty from the moment a file exists.

If you want a site that sends nothing at all, that is a different requirement from "does not upload my audio", and this page will not pretend otherwise. The claim being measured here is narrower and checkable: the audio is not transmitted, and no request is made while it is being processed. Details of what is collected and why are on the privacy page.

A converter that runs on a server has to receive the audio before it can analyze it — that is not a policy choice, it is what the architecture requires. The file leaves your machine because the code that reads it lives on someone else's. Here the code that reads it is already in the tab: the browser decodes the file into an in-memory audio buffer, the pitch search runs over that buffer, and the note list is written into a new binary object in the same tab.

That is why the request log stays empty rather than merely short. There is no stage in the process where the audio exists as something sendable — it is a decoded buffer in memory from the first moment to the last, and the only artifact that survives is a MIDI blob you choose to save.

What the tool does and does not do with that audio is a separate question from where it goes; the converter overview covers the single-pitch limitation that decides whether a given file is worth converting at all.

1. Open the network panel. In Chrome or Edge press F12, choose the Network tab, and reload the page. You should see the six requests listed above and nothing else.
2. Clear the list. The clear button empties the panel without reloading the page, which is what makes the next step meaningful.
3. Convert a file. Choose your own recording and press convert. Watch the panel while it runs.
4. Read the result. A new row means a request was made. On this converter there should be none, and the download should appear without adding one.

If you would rather not use DevTools, there is a blunter version: load the page, take the machine off the network, then convert. We did not run that variant, so treat it as your test rather than our result — but it measures the same thing from the opposite direction, because a conversion that depends on a server has to make a request, and this one made none. Whichever route you take, the thing to look for is a request appearing between the file being chosen and the MIDI being ready: that is the only window in which an upload could hide.

Applying the same test to another tool is the fastest way to compare them, and it needs no trust in anyone's marketing copy. The tool comparison covers the workflow differences; this page only covers the traffic.