Compress Video to a Target Size

Shrink a video to an exact file size (8MB, 10MB, 25MB, 50MB or custom) for Discord, email or upload limits. Runs in your browser, free and private.

šŸŒ EspaƱol

Drop your file here (.mp4, .mov, .m4v, .webm)

šŸ”’ Private by design: your files are processed locally in your browser and never uploaded to any server.

Written and maintained by Last updated

The arithmetic behind an 8 MB Discord cap

Most compression tools ask how much quality you are willing to lose and let the file size land wherever it lands. That is the wrong question when the number has already been decided for you. Discord, Gmail, a ticketing system or a job application portal states a ceiling, and one byte over it means the upload is refused.

Working backwards from a size takes two steps, and this tool does both before it encodes a single frame. First it runs FFmpeg over your file with no output file at all, purely to read the Duration: line out of the log. Then it converts your chosen target into a bit budget and divides that budget by the clipā€™s length.

The conversion counts a megabyte as 1024 x 1024 bytes rather than a round million. That is worth knowing rather than reassuring. A platform advertising ā€œ8 MBā€ normally means the decimal 8,000,000 bytes, and the binary megabyte is about five percent larger, so the budget is aimed a little above such a cap rather than safely under it. Check the size of the finished file against the limit before you upload, and pick the next size down if it is refused.

Concretely, a 10 MB target becomes 10 x 1024 x 1024 x 8 bits, which is roughly 83,886 kilobits. Spread that over a 60 second clip and the whole file may average about 1,398 kbps. Subtract the audio reservation and around 1,302 kbps is what the video encoder is asked to hit.

Where the 96 kbps audio reservation comes from

Sound is not free. Before any video bitrate is worked out, a flat 96 kbps is carved off the top for AAC audio, and the encode then asks for exactly that figure, so the reservation and the reality agree on any clip that has a soundtrack. A silent source still pays the reservation, because nothing here checks for an audio stream before doing the arithmetic. 96 kbps is lower than the 128 kbps this siteā€™s general purpose converters reach for, and that is the point: a tool whose only job is clearing a hard ceiling would rather spend the remaining bits on the picture.

That reservation is also what makes some requests impossible. If a clip runs long enough that 96 kbps of audio alone would swallow the entire budget, no positive video bitrate is left and the run stops before a single frame is encoded. FFmpeg has been started by then, because the duration the check depends on is read out of its analysis log, but nothing is written. For an 8 MB target that boundary sits a little under twelve minutes of footage; for 25 MB it is a bit over three times further out.

Two clamps catch the opposite extremes. A computed video bitrate under 125 kbps is raised to 125 kbps, because x264 below that is blocky past the point of being worth encoding, and the honest consequence is that the file then comes out larger than you asked for. A computed bitrate over 20,000 kbps is capped there, which only happens with a very short clip and a generous target and costs you nothing you could see.

Running a two-pass size-targeted encode

  1. Drop your video into the box above, or click Choose a file. MP4, MOV, M4V and WEBM are accepted.
  2. Pick a Target file size. The presets are the caps people search for by name. The Custom size (MB, only used when ā€œCustom sizeā€¦ā€ is selected) field is always on screen, but its value is only read once the select is on Custom sizeā€¦, and it accepts 1 to 2000.
  3. Click Compress Video to a Target Size. The bar covers the analysis pass from 0 to 50 percent and the real encode from 50 to 100 percent.
  4. Download the result. It keeps your original filename with -compressed.mp4 on the end.

When the target size is impossible for that clip

Infeasible combinations stop early, but the message on screen is the shellā€™s standard one: something went wrong, check the file is valid and try again. The detailed reason, naming how much space the audio track alone would need, goes to your browserā€™s developer console instead. The same applies when the duration cannot be read out of the log, which usually means a truncated or half-written file.

Nothing is lost when that happens. Your file stays in the list, so you can raise the target size, or switch to Custom sizeā€¦ with a larger number, and click the button again without re-adding anything.

Choosing between this and the CRF-based Compress Video tool

Compress Video works the other way round. It encodes at a constant quality level and lets the size fall where it falls, which is the better tool when you want ā€œnoticeably smallerā€ and have no specific number in mind. It accepts MP4 alone, so a MOV, an M4V or a WEBM has to be converted first. This page exists for the case where the number is the requirement, and the quality is whatever survives it.

There is a third option that people reach for too late: making the clip shorter. Thirty seconds at a comfortable bitrate beats four minutes at the floor almost every time, and Trim Video does that without re-encoding anything. For the wider picture on which tool suits which job, see the video converter and compression guide or browse all the video tools.

What the compressed MP4 gives up

This is a real re-encode, so it is lossy, and no setting here will change that. Every frame is decoded and re-compressed with libx264 at the fast preset in yuv420p, targeting the computed average bitrate across two passes. What comes back is a valid, broadly playable MP4 that is genuinely smaller, not a bit-for-bit copy of your source at a smaller size, and why re-encoding loses quality explains what actually disappears in the process.

Worth knowing before you judge the output: the resolution is left alone. Nothing here downscales 1080p to 720p to make the numbers work, so a tight budget on a large frame buys fewer bits per pixel rather than fewer pixels. That is the usual reason a heavily compressed clip looks mushy in motion but fine on a still frame.

Frequently asked questions

Does the output land exactly on 8 MB, or just near it?

Near it, not on it, and not guaranteed to be under it. The budget is calculated with a megabyte counted as 1024x1024 bytes, so an "8 MB" target aims at 8,388,608 bytes, while a platform stating 8 MB usually means the decimal 8,000,000. The binary figure is about five percent larger, so the arithmetic aims slightly above such a cap rather than below it. Two-pass encoding also lands close to an average bitrate rather than hitting it exactly. Read the result as an approximation, check the finished size, and drop to the next size down if the limit is being enforced strictly.

Does it lower the resolution to hit a small target?

No. The only scaling applied is a rounding filter that forces the width and height to even numbers, because H.264 rejects odd frame dimensions. A 1080p clip squeezed into 8 MB stays 1080p and spends its few bits per frame there, which is why a long clip at a tiny target looks blocky rather than small and sharp. Shortening the clip is usually a better lever than the target size.

Why do I have to wait through two encoding passes?

libx264 only knows which parts of a clip are hard to compress after it has looked at all of them once. The first pass writes a statistics file and produces no video at all (audio is skipped entirely with -an), and the second pass reads those statistics to spend the fixed bit budget where it matters. The progress bar covers pass one from 0 to 50 percent and pass two from 50 to 100.

What happens when the clip is simply too long for the size I picked?

The run stops before FFmpeg encodes anything, because the fixed 96 kbps audio reservation already consumes the whole budget. For an 8 MB target that boundary sits a little under twelve minutes of footage. On screen you get the tool's standard failure message; the specific explanation, including how many megabytes the audio alone would need, is written to the browser console.

My 40-minute recording came back bigger than the size I asked for. Is that a bug?

No, that is the video bitrate floor doing its job. When the computed bitrate falls below 125 kbps the tool uses 125 kbps instead, on the grounds that a technically-smaller file nobody can watch is worse than an honest overshoot. Pick a larger target or cut the recording down first.

Which container and codec do I get back?

An MP4 holding H.264 video, plus AAC audio at 96 kbps whenever your source actually carried an audio track, whatever container you fed in. The second pass adds the faststart flag, which moves the file index to the front so a player or an upload form can read the duration from the first few kilobytes instead of downloading the whole file.

Related tools