Browser support and memory for large files

The converter starts only in a desktop browser that looks like Chrome, Chromium, or Edge and that exposes Worker and WebAssembly. Large files are limited by memory in that tab, not by a published duration cap. There is no public file-size limit yet.

Open the converter

The browser check

The processing page reads navigator.userAgent. It looks for Chrome, Chromium, or Edg, and it rejects the string when it also contains Mobile, Android, iPhone, or iPad. It then checks that Worker and WebAssembly exist on the window. If either check fails, the page shows "Conversion blocked in this browser" and does not offer a file picker for a task. The explanation on that page can still be read.

The acceptance set the project uses is recent desktop Chrome and recent desktop Edge, on Windows and on macOS. The code does not also test the operating-system name, so the string check is what you hit. A browser that pretends to be Chrome can be let through or kept out for the wrong reason. The page does not claim it can see past a disguised user-agent. Safari, Firefox, and mobile Chrome are outside the check as written today. Content pages such as this one do not run that gate. You can read them anywhere.

The converter uses a Worker so the encode does not live on the tab's main thread, and it uses WebAssembly for the actual media tool. Both have to exist. A locked-down browser that reports a Chrome user-agent but withholds those APIs still fails the second check.

What has to load before your file is touched

The WebAssembly program is fetched from the processing site. The public default build is the single-threaded one. If that fetch fails, you get core-load-failed. The page tries the load three times, with a pause between tries, then stops. A response that ends early counts as a failed load, so the next try can fetch the program again. Your file is still local. A content blocker that stops the processing site's own scripts will look like a broken converter. Allow the processing origin to load its program, then start the task again.

The program is large enough that the production worker reassembles it for the browser from pieces. You do not pick those pieces. You only see success, or a load error. This is ordinary site traffic. It is not an upload of the video.

Why memory follows the decoded audio

The page reads the entire file into memory, then copies it into the converter's workspace. Inspection then decodes every audio track completely, before you have pressed convert, to find truncation. Verification later decodes the selected track again and decodes the MP3 as 16-bit PCM, and it holds those buffers while it compares them. A short, highly compressed file can still hide a long timeline. Silence compresses well. The decoded samples do not.

At 48 kHz, 16-bit PCM is 96,000 bytes per second for mono and 192,000 bytes per second for stereo. A five-minute stereo timeline is about 55 MiB of PCM. A thirty-minute stereo timeline is about 330 MiB. The page can hold more than one such buffer at once, plus the original file, plus the converter. A 5.1 source is downmixed, but the file still had to be read and inspected first. Memory on the machine, not the bitrate of the MP3, is what makes a long file risky.

The on-screen memory figure, when the browser provides performance.memory, is the JavaScript heap the browser chose to expose. It is not the whole process, and it is absent in browsers that do not expose it. "Not measured" means the figure was not available. It does not mean the tab used no memory.

Measurements that are not a promise

There is no public file-size limit and no public duration limit. Publishing one would require the lowest computers the product accepts, and those runs are not what a single virtual machine can stand in for. The addressing cap in the code is 2,147,483,647 bytes. Crossing it is an immediate refusal. Staying under it only means the file can be named as a buffer. It does not mean the tab will survive the decode.

Project notes from one virtual machine, not a support promise, record that noisy files around 10, 50, 100, and 200 MB reached a saveable result on that machine, with the 200 MB case using a JavaScript heap of about 3.3 GiB. A further file of 303,150,578 bytes, about twelve thousand five hundred seconds of audio, failed. Its decoded PCM was 2,400,000,000 bytes, the browser refused to transfer an array that large, and the page ended the task as task-timeout after 788.7 seconds. The same notes say a thirty-minute near-silent file finished on that virtual machine and still used hundreds of megabytes of heap. None of these sentences is a limit for your computer. They are a warning that decoded size dominates.

Habits that match the way the page works

Close other heavy tabs before a long file. Keep the converter tab in the foreground if you can. Hidden time and sleep are not counted as progress, but the memory does not go away while the machine sleeps, and a stall during foreground time ends the task with no partial file. Do not refresh to "nudge" a percentage. Refresh throws the task away. There is no resume.

If the tab is killed by the operating system, that is a failed task. You may retry once from the original file if the page is still there to offer the button. If the tab is gone, open the converter and start again. That new visit is not a second retry of a still-open task. It is a new page. The one-retry rule applies inside a visit, to the same input, after a failure or a cancellation.

Prefer a shorter export if you only need a clip. The tool cannot trim. It converts the selected track's full effective duration. A smaller file is the only size control you have, and even a small file fails if the codec or the channel layout is outside the list. The formats guide is the list. The troubleshooting guide is the code you will see if memory, the stall timer, or verification stops the run.