The Drop · September 22, 2026

Does my music get uploaded anywhere? What a browser visualizer does with your file

If the track is unreleased, this is the question you ask before you drag it into anything. The answer here is that there is nowhere for it to go.

Photo via Unsplash

Plenty of people will not hand an unreleased demo to a free online tool, and that instinct is correct. Most sites that offer to make you a video want the file on their server, because that is where their software runs. A browser tool is a different shape, and the difference is worth being able to check rather than take on trust.

The short answer

Your track is never uploaded, because there is nothing to upload it to. This site is static pages and the app is a single HTML file. No server takes a job, no queue, no account, no database. When you pick a song, the browser reads it off your own disk into the memory of that one tab, draws frames from it, and hands you a video back. The song never crosses the network.

That is not a promise about intentions, it is a description of what the code can do, and you can confirm it yourself in a minute without trusting a word of this.

What actually happens to the audio file

Start with what is missing. The classic way a file reaches a server is a file input sitting inside a form, which the browser posts to whatever address the form names. There is no form element anywhere in this app and no form action, so that path does not exist. The file input stands alone and hands the file straight to JavaScript.

From there the whole audio journey is one line:

audioBuffer = await audioCtx.decodeAudioData(await file.arrayBuffer())

Both halves are ordinary browser APIs that work locally. MDN describes what arrayBuffer() returns as "a promise that resolves with an ArrayBuffer that contains the blob's data in binary form", which is your file's bytes sitting in the tab's memory. decodeAudioData turns them into samples and the analyser reads the samples to find the beat. Images take a similar route through createObjectURL, which produces a blob: address that only means anything inside the page that created it.

Then there is the absence, which is what actually settles the question. Search the app for the things that send data out of a browser, a short list: fetch, XMLHttpRequest, WebSocket, sendBeacon, FormData. No matches. Not one. There is no code here capable of transmitting your track anywhere, which is a stronger statement than a policy promising it will not.

Check it yourself, it takes a minute

Every browser ships a panel listing every request a page makes, and you do not need to be a developer to read it. On Chrome press Control and Shift and J, or Command and Option and J on a Mac, then click the Network tab. One detail first: Chrome's own documentation notes that "DevTools only logs network activity while it's open", so open the panel, then reload the page.

Now use the tool normally. Load a song, preview it, run a render, download the result, and watch the list while you do. You will see the page, a pile of font files, a couple of analytics scripts, and then nothing further while you work. There is no row the size of your track and no request leaving with it. Sort by Size and the largest thing that ever crossed the wire is a font, not your five megabyte song.

For a second check that does not depend on watching, look at the page's response headers and find Content-Security-Policy. The part called connect-src lists the only addresses this page is permitted to open a connection to, and the browser enforces it rather than the site. It holds this domain and the two analytics hosts below. There is no upload endpoint on that list to send a file to even in principle.

What the page does load

A page that claimed to talk to nothing at all would be lying, so here is the whole list.

• Fonts. The app carries fifty display typefaces and pulls them from this same domain at startup. That is most of the traffic you see in the panel.
• Two analytics scripts, one from Google and one from Cloudflare. They record that a page was viewed, roughly where from and on what kind of device, the same visit data almost every site collects. They run before you pick a file and have no path to it.
• The page itself, served like any other website. Whoever serves a site can see somebody requested it.

None of those touch the audio. A site knowing a visit happened and a site receiving your unreleased song are different things, worth keeping apart rather than treating any request at all as a leak.

Where the finished video comes from

The render is the other place people expect a server to appear, because on most tools that is the moment the work gets sent off to be processed. Here the recorder collects frames as the track plays, the pieces are assembled into one file in the tab, and the Download button points at that file in memory.

Which brings up the flip side, worth saying plainly: nothing is stored either. The app writes no cookies and uses none of the browser's storage, so a refresh takes your settings, your uploaded images and your unsaved render with it. A tool with nowhere to put your work also has nowhere to keep it. Rendering a whole album therefore has to be one long browser session, which is worth knowing before track seven.

What no upload does not mean

Three honest limits, because the phrase gets stretched further than it should. The first is that it says nothing about the computer you are sitting at. The finished video lands in your downloads folder, and on a shared or work machine that is a file somebody else can open. If the track is sensitive, the machine matters more than the website does.

It says nothing about what happens after you post the result. The moment a visualizer goes up on YouTube it is subject to everything that applies to any upload there, including automated matching against the rights databases.

And it is not a claim about every browser tool. Plenty of sites in this category render on their own machines, which is why the question is worth asking each time. The scope piece on free music video makers covers what you give up with a browser only tool, because there is a trade.

The short version

• No form element, no upload code, no account. The audio is read into the tab and stays there.
• One line does the work, decodeAudioData on the bytes of your file.
• Open the network panel, reload, then render. Your track never appears in the list.
• The page loads its own fonts and two analytics scripts. That is visit data, not your song.
• Nothing is stored either, so a refresh clears the session along with everything in it.

The question people usually ask next is whether any of it runs on a phone, and that one has a real answer rather than a reassuring one: the mobile post goes through what a phone browser can and cannot do here.