Does MP3 to MIDI conversion upload your audio?

No — not on this site, in the run we measured. We performed a real conversion while recording every network request the browser made. There were 11 requests. None was a POST, PUT, or any request carrying a body. Only two external hosts appeared: a public model CDN and a host-injected analytics script that this page's Content Security Policy blocked. The audio file itself was not sent anywhere in this run.

Measured on 6 November 2026 in Chrome 156.0.8078.80 on Windows, with one 4.8-second synthesised WAV containing four notes. This is a report of one run, not a guarantee about every browser, every extension, or every file. The input in this run was WAV, not MP3.

What we measured

We generated a WAV file locally: four sine-wave notes (261.63, 329.63, 392.00 and 523.25 Hz), 1.2 seconds each, mono, 16-bit, written at 22,050 Hz. Then we opened the public converter page, selected that file, pressed Convert to MIDI, and recorded the browser's network activity together with the conversion report that the page produces itself.

The requests

Three of those external requests were GETs for the publicly hosted runtime and model files. The page's own conversion report recorded each one:

These are public package files fetched from a CDN so the model can run inside a Web Worker. They are inbound downloads, not outbound copies of your recording. The site's response header restricts what the page may load:

content-security-policy: default-src 'self'; script-src 'self' 'wasm-unsafe-eval'; style-src 'self'; font-src 'self'; img-src 'self' data:; worker-src 'self' blob:; connect-src 'self' https://cdn.jsdelivr.net blob:; media-src 'self' blob:; object-src 'none'; base-uri 'self'; form-action 'none'

The hosting platform injects a Cloudflare Insights script into served pages. In this run that script was blocked by the script-src 'self' rule above, which is the one failed request in the table.

What came out

The four notes in the WAV produced four notes in the MIDI file. That is a result for this one synthetic file; it says nothing about how a full song, drums, or vocals would behave.

Where the time went

Model loading is a separate cost from detection. On a later conversion in the same tab, cache behaviour may differ; we did not measure a second run.

Three diagrams from the same run

Each diagram is drawn directly from the measurement file of this run, so the numbers in the images match the tables above.

What this measurement does not prove

• One run, one synthetic file, one browser build. We did not repeat it across browsers, devices, or network conditions.
• The input was WAV. We did not test an MP3 here, so this page makes no claim about how lossy compression changes detected notes.
• The CDN can observe that a client requested those three public model files. We did not inspect what any CDN logs.
• The host-injected analytics script was blocked in this run by the CSP. We did not test a browser or extension that overrides that policy.
• We did not audit browser extensions, server-side logs, or the hosting platform's own processing. Our observation is limited to the browser's network activity and the page's own report.

How to repeat this check yourself

1. Open the converter and your browser's developer tools Network panel before selecting a file.
2. Choose a small MP3 or WAV, then press Convert to MIDI.
3. In the Network panel, look for POST, PUT, or PATCH requests, and inspect any request that has a payload. In our run there were none.
4. Check that the external requests are GETs for the model and runtime files on cdn.jsdelivr.net.
5. Press Download conversion report on the result panel. It contains the input hash, output hash, note count, timings, parameters, and the resource list shown above, so you can compare your own run with this one.

Short answers