The free limits on popular audio converters

They hit a wall on one site and want to know whether the next one will do the same, or they are choosing before they start. The numbers are scattered across pricing pages, FAQ articles and modal dialogs, and several of them are widely misquoted.

Every free online audio converter caps something, and there are only about five things it can cap: how big one file may be, how many jobs you get per day, how many minutes of audio you may process, how many conversions may run at once, and how long the finished file stays available for you to fetch. Which one bites you depends on the service and on whether you are signed in. What this page will not do is print the current figures, because the figures move: of the free-tier numbers gathered while researching this site, three were already out of date against the services' own pricing pages by the time they were checked. Numbers copied off a blog post from two years ago are worse than no information. Below is the shape of each limit, how to read the real number off the site you are actually on in under a minute, and what happens at the moment you hit the wall.

Why this page prints no numbers

Free-tier limits are a pricing lever, not a technical constant. They get tightened when infrastructure costs rise, loosened during a growth push, and quietly restructured whenever a service moves from counting files to counting minutes. A page that hard-codes "the free plan allows X" is wrong within a year and stays wrong, because nobody goes back to re-check an old article. Most of the results you will find for these searches are exactly that: one page copied the figure, six copied it from that one, and the original was a screenshot of a modal dialog.

There is a second reason, which is that a single number rarely describes the limit anyway. On most services the anonymous visitor, the free signed-in account and the expired trial all get different allowances from the same page, and the marketing copy quotes whichever is largest. So the useful thing is not the number. It is knowing which lever the service pulls, so you can spot it and check it yourself.

The five shapes a free limit takes

Almost every restriction you will meet is one of these. Recognising which one you have hit tells you immediately whether waiting helps, whether splitting the file helps, or whether nothing helps short of paying.

The names you will see in the search results map onto this list predictably. CloudConvert meters in conversion minutes, so a single long recording can cost you more than a dozen short ones. Zamzar and Convertio both lead with a per-file size cap, which is why a long lecture recording bounces off them before a short song does. FreeConvert combines a per-file cap with a daily count, so two different walls can stop you on the same afternoon. Those structures are stable. The figures attached to them are not, so check them where they are published rather than trusting this paragraph or any other.

How to check the real number in under a minute

Three places, in this order.

1. The pricing page, not the home page. Every service that limits a free tier documents it where it is trying to sell you the paid one. Look for the free column of the comparison table. This is the only figure with a date attached to it, in the sense that it is the one the company is currently maintaining.
2. The error itself. When a cap fires it almost always states the number in the message. That is the authoritative version for your account, your region and today. Read it before you close it.
3. The terms or FAQ, for the things pricing pages omit. Result expiry and retention are rarely in the comparison table. They are in the FAQ, and they are the part worth reading if the recording is confidential. Checking whether a converter really keeps your file local covers how to tell a retention promise from a retention mechanism.

What is not worth doing is testing the limit by feeding it your real file. If you are close to a size cap, you learn the same thing from a throwaway file of a similar size, without a copy of the confidential one sitting on someone's disk while you find out.

What actually happens at the wall

Rejection is the honest outcome and the most common one: the job never starts, and you have lost only the time it took to try. Two other outcomes are worth watching for, because both can look like success.

• A silent downgrade. Some services cap the output rather than refusing the input, handing back a shorter clip, a lower bitrate than the one you selected, or a mono file where you asked for stereo. Check the duration and the size of what you got before you send it on.
• An indefinite queue. A concurrency cap does not fail, it waits. If a short file has been "processing" for several minutes, you are in a queue behind paid traffic, and there is nothing on your end to fix.

None of these are scandals. They are what it costs to run other people's audio through your own machines and give it away. The point is only that a queue and a cap need different responses, and the page rarely tells you which one you are in.

Why a converter that runs in your browser has no daily counter

Every limit in that table exists because the work costs the operator money that scales with your usage. A converter built out of WebAssembly has a different bill entirely. The code is a static file, served once and cached; the conversion runs on your own processor, in your own tab, and the operator's costs do not move whether you convert one file or two hundred. There is nothing to ration, so no counter is written, so no wall exists to hit. Nothing about your audio is sent anywhere for this to work, which is also why there is no size cap of the kind other services must impose.

That is a genuine structural difference rather than generosity, and it comes with its own trade. The engine has to reach you before anything can happen, and your device has to do the arithmetic. Converting an M4A to MP3 here costs you a one-off engine download and then roughly real-time encoding on a laptop; on a server-based service it costs you a wait for the queue and a transfer in each direction. Which is faster depends mostly on your connection and your machine, not on the software.

The limits this site does have, stated plainly

A comparison page that claims its own side has no constraints is not a comparison page. Ours are these.

The 300 MB and 2 GB figures are not a policy and cannot be raised by paying, which is the difference between a ceiling and a cap. What to do when a converter says the file is too large goes through the options for a recording that is genuinely too big for a tab, including splitting it and dropping the bitrate before the encode rather than after.

When a server-based service is still the right answer

There are cases where paying for someone else's machines is simply correct, and pretending otherwise would be dishonest.

• The file is enormous and your device is not. A four-hour multitrack session on an old laptop will fail in a tab and succeed on a server. The address space is the constraint and no amount of patience fixes it.
• You need it automated. Batch pipelines, watched folders and API calls are what the paid tiers of these services actually sell, and a browser tab is the wrong tool for a nightly job.
• You need a format nothing local writes. Obscure broadcast and telephony codecs are a real use case, and a large hosted converter will cover more of them than any single build.
• You are on a locked-down machine. Some managed browsers block WebAssembly outright, in which case nothing running client-side will start.

Outside those, the calculation is straightforward. If the limit that stopped you was a daily count or a queue, it is a business decision by someone else, and it disappears the moment the work happens on your own hardware instead of theirs.