Every free online video tool has a size limit, and the limits are usually surprisingly low. If you have tried to trim a two-hour screen recording or a 6 GB drone file, you have run into one.
There are two entirely different reasons a tool imposes a cap, and knowing which kind you are dealing with tells you what to do about it.
Why server-based tools cap file size
If a tool uploads your file, then every megabyte you send costs the operator inbound bandwidth, temporary storage, CPU time on a machine they rent, and outbound bandwidth to send the result back. That is a real, per-file, per-user cost, paid by a business giving the service away.
The cap is therefore not a technical limit at all. It is a budget. That is also why the cap is usually the first thing behind the paid tier: it is the cost the operator most wants you to cover.
A secondary consequence people underestimate: the upload itself is the slow part. Domestic connections are asymmetric, and upstream is often a fraction of downstream. A 4 GB file on a 20 Mbps upstream link takes well over half an hour to send before any processing begins.
Why a browser-based tool has a different ceiling
A tool that runs FFmpeg compiled to WebAssembly inside the page never sends the file anywhere, so none of those costs exist and there is nothing for the operator to ration. There is no server-imposed cap on this editor because there is no server in the path to impose one.
What there is instead is a memory ceiling, and it is worth understanding precisely because it behaves differently from a file-size cap.
The heap is 32-bit. The FFmpeg WebAssembly build is a wasm32 module, which means its linear memory is addressed with 32-bit pointers and can never exceed 4 GiB no matter how much RAM your machine has. In practice you get less: browsers allocate the heap in chunks and will refuse to grow it long before the theoretical ceiling, and the module is typically built with a maximum lower than 4 GiB anyway.
Everything is in that heap at once. The input file is read into memory as a byte array and written into FFmpeg’s in-memory filesystem. The decoder’s frame buffers live there. The encoder’s output accumulates there. Then the finished file is read back out into a Blob. For a period in the middle, you are holding roughly the input plus the output plus the working set simultaneously.
Your device’s RAM is the other half of it. Even when the WebAssembly heap could grow, the browser will not hand out memory the operating system does not have. A 4 GB Chromebook and a 32 GB workstation have very different real ceilings for the same file.
The practical result: a few hundred megabytes is comfortable almost anywhere. One to two gigabytes works on a desktop with headroom. Beyond that you are gambling, and the failure mode is the tab reloading itself rather than a polite error message.
What to do about a file that is too big
In rough order of how much they help.
1. Cap the output resolution
This is by far the biggest lever, and it is one control. Setting max resolution to 720p on a 4K source means the encoder is dealing with roughly a ninth of the pixels. The encode finishes far sooner, the peak memory is much lower, and the output file is dramatically smaller.
Ask what the video is for. If the destination is a message, a social post, a slide, or a web page, 720p is almost certainly sufficient and 4K is almost certainly waste. The control only ever scales down, so a 480p source is never blown up.
2. Cut before you do anything else
If the thirty-minute recording only needs four minutes of it, make the cuts first. The output is proportionally smaller, and everything downstream gets easier.
Counter-intuitively, this does not reduce the peak memory of that first pass much — the whole input still has to be loaded to cut it. But it makes every subsequent operation cheap.
3. Split the work into passes
If a single edit will not complete, do half the video, then the other half, then join them. Each pass has a smaller working set. The cost is an extra generation of re-compression on whatever you process twice, so do as much as possible in one pass within each half.
4. Choose MP4, not WebM
WebM output has to use VP8 and Opus, because those are the codecs the container is defined around. VP8 encoding in WebAssembly is substantially slower than H.264. Unless you specifically need WebM, MP4 is faster, smaller in peak working set, and plays in more places.
5. Close everything else
Other tabs are competing for the same memory. On a laptop with 8 GB or less this is not a marginal suggestion — it is often the difference between a completed encode and a reloaded tab.
6. Use a desktop, and a 64-bit browser
Phones have far tighter per-tab memory limits than desktops and are aggressive about reclaiming memory from background tabs. A long recording on a phone is the worst case for this kind of tool. Short clips on a phone are fine; a two-hour 4K file is not.
7. Past a certain size, use FFmpeg directly
There is a point where the honest answer is that a browser tab is the wrong container for the job. Desktop FFmpeg streams from disk rather than holding the file in memory, so it has effectively no size ceiling at all.
If your cut is at the ends of the clip and a second of imprecision is acceptable, it is also lossless and instant there — no re-encode, no quality cost, no waiting. The exact commands are here. For a 6 GB source that is not a fallback, it is the correct tool.
A rough guide to what will work
| File | Expect |
|---|---|
| Under ~200 MB | Fine essentially anywhere, phones included |
| 200 MB – 1 GB | Fine on a desktop or laptop with headroom; slow on a phone |
| 1 – 2 GB | Works on a machine with plenty of free RAM; cap the resolution |
| Over 2 GB | Unreliable in a browser tab. Cap resolution, split the job, or use desktop FFmpeg |
These are ranges to plan around, not guarantees — the outcome depends on your device, your browser, what else is open, and the resolution and length of the source. The one thing you can rely on is the direction: lower resolution and shorter duration always help, and they help a lot.
What you get in exchange for the ceiling
It is a real limitation and worth weighing honestly. What it buys is that a 3 GB recording of something you would rather not hand to a stranger is edited on your own machine, with no upload wait, no retention policy, no account and no watermark. For most files most of the time, that is a good trade — and when it is not, the command line is right there.
More on the mechanism: how browser video editing works. More on the privacy side: what a private video editor actually means, and how to verify the claim yourself.