← Blog

Convert large files to MP3 with no limit: how mp3fy does it

By Sam Ortega · Engineering notes20 August 2026· 6 min read

Every free online converter hits the same wall in the same place. 100 MB, sometimes 50, occasionally a generous 500. Then the modal, the price table, the little “Pro” badge. You found the site because you have a big file; the site exists because you have a big file; and the one thing it won’t do for free is convert a big file.

The wall is dressed up as a technical constraint. It isn’t one.

A file-size cap is a business model. The free tier demonstrates the product; the cap sells the subscription. No law of computing says an MP3 encoder gives up at 100 MB. Encoders chew through terabytes without complaint. What actually creates limits is one architectural decision: buffering. If a converter holds your entire file in a server’s RAM, or funnels it through a single HTTP request, or parks it on one machine’s disk before work begins, then somebody has to pick a maximum. And once a maximum exists, it migrates to the pricing page.

mp3fy is built on the opposite decision. Every stage of both conversion paths streams. Your file never sits anywhere as one complete blob, so there is no number to pick: no cap at 100 MB, none at 20 GB, none at 10 hours. That has been the rule since 2015.

Here is how both paths hold it.

On your device, memory stays flat

The default path never uploads anything. Your file is converted in the browser, on your own machine, which already removes the most common excuse for a cap: upload infrastructure costs money, and capping uploads saves it.

But local conversion hits its own wall if you do it naively. Read a 3 GB video into memory and the tab dies long before the encoder runs. So the device engine never loads the file. It reads a small chunk, demuxes it, decodes the audio samples, hands them to the MP3 encoder (LAME, compiled to WebAssembly), appends the finished frames to browser storage rather than RAM, and throws the chunk away. Then the next chunk. Repeat until done.

The working set at minute six hundred is the same as at minute one. A 3 GB file does not need a thousand times the memory of a 3 MB file; it needs the same memory for a thousand times as long. And even “long” is relative. The device engine typically runs at 20–80× realtime, so an hour of audio encodes in a couple of minutes on an ordinary laptop.

None of this is exotic. It’s how every video player works: nobody expects a player to load the entire movie before showing frame one. Conversion is the same problem, with the output going to disk instead of a screen. The surprising thing isn’t that streaming conversion is possible. It’s how many converters buffer anyway.

A 10-hour recording is just a longer progress bar.

In the cloud, nothing passes through a bottleneck

Some formats a browser can’t decode, and some devices are too slow to bother. That work goes to the cloud path, which is where most converters’ caps actually live, and where ours had to be engineered away twice.

First, the upload. Your file never passes through our web server, because web servers are exactly where request-body limits come from. Instead, the browser slices the file into chunks and sends them in parallel, straight to object storage. Each chunk is an ordinary small request; a 20 GB file is simply more of them in flight at once. No single request ever carries the whole file, so no request limit ever applies to it. Parallelism also makes the upload fast: many streams saturate your connection where one stream trickles.

Second, the conversion. An input of 60 minutes or less gets a plain single-pass encode on one machine running native ffmpeg; the simple case stays simple. Longer inputs are split into roughly 30-minute segments, and every segment converts simultaneously on its own machine. A 10-hour recording becomes about twenty encodes running at once, and the wall-clock time collapses to roughly the length of the slowest segment instead of the sum of all twenty.

Splitting is where this usually goes wrong. Cut an MP3 carelessly and every join adds a few milliseconds of silence: inaudible once, audible twenty times over, fatal if the audio has to stay in sync with video. Our segments are cut sample-accurately on MP3 frame boundaries and reassembled without a frame of padding, so the stitched output matches what a single-pass encode would have produced. The frame math has enough sharp edges that we wrote it up on its own.

And then everything is destroyed. The upload is deleted the moment conversion finishes. The output expires one hour after your first download, or 24 hours after creation at most. The privacy page has the full retention story.

The receipts

Claims are cheap, so here are the numbers from our test runs on the nastiest shape of file we could produce: one continuous 10-hour recording.

Four of those rows deserve a second look.

The output is roughly three and a half times larger than the input, and nothing anywhere had to care. Size never mattered at any stage, in either direction.

The upload took 46 seconds because parallel chunks did their job. No single connection had to haul 152 MB alone.

The conversion ran at roughly 220× realtime. That is not one heroic machine; that is twenty ordinary machines each doing one boring half-hour job at the same time.

And the output duration matched the source to three hundredths of a second, across ten hours, through twenty cuts and twenty joins. That’s the frame-boundary reassembly holding under load.

What is limited, and why

None of this means unlimited everything for everyone at once. Compute is real and abuse is real, so there are exactly two limits, and neither one reads your file.

You can run three simultaneous cloud jobs. And there’s a rate limit on how fast new jobs can be created.

Both are abuse controls. They stop a script from queueing a thousand conversions a minute and keep the machine pool available for actual people. Neither looks at size or duration; to the limiter, a 20 GB input and a 20 MB input are identical: one job each.

Notice what’s missing: a paid tier behind the limits. There isn’t one. mp3fy has been free since 2015 and runs on donations, which is exactly why its limits can be honest abuse controls instead of conversion funnels.

What this means when you have the file

Here’s the quiet irony of the 100 MB wall: the files it excludes are the ones people most need converted. Nobody reaches for a converter over a 4 MB song. The moment of need is the 10-hour lecture recording, the concert video that landed as a 20 GB MKV, the decade of voice memos sitting in M4A, the podcast backlog. Those are precisely the files the wall was positioned in front of.

Here they are first-class inputs: same converter, same formats, same price of nothing. Drop the file. Get the MP3. Keep your money.

Limits are an architectural choice. We made the other one.

Convert a file now →