"File too large" — what to do about it

They are mid-task, already frustrated, and just got blocked by a size limit on a site they were using. This is the highest-intent moment in the whole funnel: they have a specific file, a specific competitor, and an immediate need.

The limit is theirs, not your file's. Nothing about a 180 MB recording makes it hard to convert; it is hard to send, and a site that has to receive the file before it can touch it pays for every megabyte in bandwidth and CPU. So it caps what it will accept. A converter that runs inside your own browser tab never receives anything, so there is no cap of that kind at all: the file is read off your disk by the page you already have open. There is still one real ceiling, and it is worth knowing about before you start on something enormous. The tab itself runs out of memory somewhere below 2 GB. Below about 300 MB you will not notice it exists.

Why the site you were using has a limit at all

A server-side converter has a bill. Your file crosses the internet twice, sits on a disk while a queue works through it, and burns CPU on a machine somebody rents by the hour. A two-hour WAV is not a rounding error on that bill, and the free tier exists to advertise the paid one. The cap is the advertisement.

The caps come in three shapes, and knowing which one bit you tells you whether the next site will do the same thing:

• A per-file size cap. The one you probably just hit. It is checked before the transfer even finishes, which is why the failure often arrives after a long progress bar.
• A job or minute budget. The file is small enough, but you have run out of conversions for the day. This one is invisible until it fires.
• A feature gate. The conversion is allowed, but batch mode, the higher bitrates or the faster queue are not.

The published figures move, and several of the numbers repeated across the web are simply out of date. We keep a dated breakdown of what each of the big services caps and what sits behind their paywalls in the free limits on popular audio converters, rather than quoting a figure here that may be wrong by the time you read it.

The route with no transfer, and therefore no transfer cap

This site's converter is FFmpeg compiled to WebAssembly. Your browser downloads the engine once, roughly 32 MB, and caches it for a year. After that the page reads your file the same way a photo editor reads an image you dragged into it: locally, through the file input, into the tab's own memory. Nothing about the audio is sent anywhere, so there is no size threshold for anyone to enforce and no queue to wait in.

The visible consequence is that a 400 MB file behaves like a 4 MB one, only slower. No account prompt, and no "your file exceeds the maximum size" at the end of a long progress bar. Drop it on the converter and it starts.

You do not have to take that on faith either. The claim is checkable in about a minute with the browser's own Network panel, or by pulling your Wi-Fi out after the page has loaded and converting anyway. Checking whether a converter really keeps your file local walks through both, and they work on any site making the same promise, not only this one.

The ceiling that does exist: your browser tab

Being honest about this is the point of the page. WebAssembly here is 32-bit, which gives the engine a hard address space of about 2 GB, and audio work needs roughly three times the file's size in resident memory while it runs: the input, the decoded samples, and the output all have to be somewhere at once.

So the converter draws two lines:

• Above 300 MB it warns you. The job will run. It will take a while, the tab will hold a lot of memory, and closing your other tabs first is genuinely worth doing.
• Above 2 GB it refuses, because that is more address space than a browser tab has. Better a clear refusal than a crash forty minutes in.

For audio these are generous lines. They matter for uncompressed recordings, multi-hour lossless sets and video files, and almost never for anything that arrived as an MP3 or an M4A.

How long a recording has to be before any of this matters

File size is bitrate multiplied by duration, and that is the whole calculation. A kilobit per second is 7.5 MB per hour, which makes the arithmetic easy to do in your head: 128 kbps is about 1 MB a minute, 320 kbps about 2.4.

Read the last column as the point where the tab starts working hard, not where it stops. The practical reading of the table: if your file is compressed, you are almost certainly nowhere near any ceiling, and whatever stopped you was somebody's business model. If it is uncompressed, an hour of it is already a serious amount of memory to hand a web page, and the sections below apply.

Check first whether you need to re-encode at all

Some conversions never invoke an encoder. If the compressed audio is already legal inside the container you asked for, it is lifted across untouched: AAC inside an .m4a going to .m4a, .aac or an .m4r ringtone, the AAC soundtrack inside an .mp4 coming out as .m4a, MP3 to MP3. These finish in about a second whatever the length, because nothing is decoded and nothing is compressed, and the audio comes out identical. Which conversions cost something covers the full list.

This does not dodge the memory ceiling, since the file still has to be in the tab. It does mean a 90-minute podcast can change container in a second instead of grinding through an encode. The converter tells you which case you are in before it starts, because it reads the codec inside the file rather than trusting the extension.

Making the file smaller, if that is what you actually needed

Often "too big" was never about the converter. It was about an email attachment, a Slack limit or an upload box somewhere else that will reject the result too. Three moves, in the order that costs the least:

1. Cut the dead air. The two minutes of room tone before anyone spoke are the cheapest megabytes you will ever remove. The audio cutter trims without re-encoding where the format allows it, so the part you keep is untouched.
2. Drop to mono. A single voice recorded to two channels is the same signal twice. Halving it is free in every sense for speech, and wrong for music.
3. Lower the bitrate. 64 kbps mono is genuinely fine for speech, 96 kbps is roomy, 128 is the sensible floor for music. Going the other way does nothing useful: asking for a higher bitrate than the source had adds bytes, not detail.

The compression tool shows the projected size as you move the settings, so you can aim at a specific number rather than converting three times to find out.

Split a long recording rather than fight it

If you are above 300 MB and the file is uncompressed, the fastest route is usually two or three passes rather than one heroic one. Convert the first hour, then the second. Each pass gets a fresh, empty allocation, so two 40-minute jobs are far more comfortable than one 80-minute job even though the total work is the same.

Two details worth getting right. Leave a few seconds of overlap at each seam if the pieces are going to a transcription service, so nothing is lost to a cut mid-word. And name the pieces in a way that sorts correctly — meeting-01, meeting-02 — because meeting-10 will sort before meeting-2 everywhere else.

When the file is on your phone

A browser tab has a memory ceiling that an installed app does not, and that gap only shows up on genuinely large files. If your recording is already on the phone and it is big, converting it there avoids both the ceiling and the trip through Drive or email to get it onto a computer first. Our Audio Converter app is free on both stores, works offline once installed, and does not fetch a 32 MB engine over cellular.

Stated plainly, because it changes the advice: the Android build does the conversion on the phone, while the iOS build's format conversion currently fails and returns an error. Its editing tools — trim, merge, fade, normalise, stereo to mono — work on both. So on Android the app is a real answer to a large file. On an iPhone, use Safari for the conversion and the app for the trimming around it.