I asked a 10 minute 1080p clip, with sound, to fit under 8 MB. The plan said it would not. I kept the first 20 seconds of the same clip, same picture, same cap. The plan said it would.
The page is Compress Video to a Size. The file stays in the tab. The number you type is the cap.
Ten minutes will not fit under 8 MB
The clip in the check is 1920 by 1080, 30 frames a second, 600 seconds, with an audio track, and the file is 900 MB. The cap is 8,000,000 bytes.
The planner walks a ladder. It tries the picture at the size it already is, then smaller edges, then a lower frame rate. At every step it subtracts the audio from the budget and asks whether the remaining video bitrate is enough bits per pixel. For that 10 minute clip, every step on the ladder fails. The reason on the plan is that the clip is too long for the cap.
That is a useful no. A page that encodes anyway and hands you a 40 MB file has not heard the number you typed.
A 10 minute 1080p clip will not fit under 8 MB. Keep 20 seconds of it and the plan fits.
Twenty seconds spends the same budget on less time
The window is start 0 and end 20. The duration the planner uses is 20 seconds, not 600. The bitrate is bits over those 20 seconds. The same 8 MB cap now has a plan that fits, and the planned output is at or under 8,000,000 bytes.
The encode itself aims at 95 percent of the cap. On an 8 MB cap that budget is 7,600,000 bytes. The gap is there so the finished file can land under the number you typed, instead of kissing it and going over. The byte count you can trust is the one after the encode. The plan is the aim.
Picture and sound are cut to the same two times. A window shorter than a fifth of a second is refused. If the end sits past the file, it is pulled back to the end of the file.
25 is 25 million bytes
The box opens at 25. That is 25,000,000 bytes, not 25 times 1024 times 1024. I use the million because that is the number people mean when they say megabytes on a file-size cap. One is the floor. 2,000 is the ceiling for the number you type. An empty box, a zero, and 2,001 are refused.
The input file has no ceiling on this page. A file over 400 MB gets a warning before you encode, because the tab can run out of memory. The warning is not a refusal. Shortening the end time is the lever that uses less of the tab.
There is no clock on the page. A phone and a desktop do not take the same time, and a guess printed as a duration would be a lie. You get a percent while the encode runs, and a Cancel button that stops it.
The plan is on the page before the encode
After the clip is read, the status line names the cap and the picture size and the frame rate the encoder will use. If the whole file is already under the cap and you are keeping the full timeline, the page does not re-encode it. You can download what you already have.
If you cut the timeline, the page encodes that stretch even when the original file was small. Returning the whole file would ignore the cut. The planner is told the original is larger than the cap so it builds a real encode for the window.
A vertical frame stays taller than it is wide. A phone file that stores 1920 by 1080 with a 90 degree rotation is turned upright before the scale, so the plan does not letterbox a portrait clip into a landscape box.
What gets smaller, and in what order
The ladder prefers a smaller picture before it drops the frame rate, and it prefers keeping some audio. Audio tries 96 kbps, then 64, then 48. A silent clip is planned with no audio bitrate at all. Video will not go below 80 kbps, and it will not go below 0.07 bits per pixel at the chosen size and frame rate. If nothing on the ladder clears both floors, the plan says the clip will not fit.
That order is the compromise you can see. You do not drag a quality slider and hope. You type a size. The page tells you the picture it has to use to get there, or it tells you it cannot.
The finished file is an MP4. The download name is the original name plus the cap, like holiday-under-25mb.mp4. There is no watermark in the picture and no tag burned into the corner.
The encoder is the one in the browser
Chrome and Edge on a computer can encode with WebCodecs. If this tab cannot encode video, the Compress button stays off and the page says so. If it can encode the picture and not the sound, it says that too. It does not send the file anywhere to finish the job.
The library that drives the encoder is Mediabunny 1.56.3, under the Mozilla Public License 2.0. I did not ship an ffmpeg build. The same planner and the same encoder already run the Discord compressor. This page is the one where you type the cap. That page is the one where the chat caps are filled in.
A picture with a kilobyte cap is a different file. That tool is the image compressor. The chat caps are the Discord compressor.
Cancel, memory, and the percent
While the encode runs, the page shows a percent from 0 to 100. Cancel stops it. A cancelled encode is not a file. The message is that the compress was cancelled.
If the tab throws a memory error, the page says the tab ran out of memory and suggests a shorter clip. It does not retry on a server. A very long source can still fail even when the plan said a short window would fit, because the browser has to open the source to read the window. That is a limit of doing this in a tab, and the page says it.
I am not going to print "about 2 minutes" on a 15 GB file. I have not measured that on your phone, and an old estimate is not a promise.
The link carries the cap, not the video
The share link has mb=25, or whatever number is in the box. It does not have the file name and it does not have the bytes. The URL is on the page before you copy it.
This browser remembers the megabyte box under softery.video-compressor.settings. Clear saved cap puts 25 back and removes the saved value. A ?v= on the address does not replace a cap you already saved. The video itself is not written to storage. Close the tab and it is gone.
Mixpanel and Google Analytics load with Softery.io. They see that someone opened the tool. A run reports a size band and a duration band. They do not get the video.
A second pass if the file is still over
The first encode aims at 95 percent of the cap. If the finished file is still over the number you typed, the page plans again at 80 percent of the cap, and never below 1 MB, then encodes once more. The result you see is that second file when the first one missed. If the second plan cannot fit either, you get the first file and the page says it is still over the cap.
That retry is the same ladder, with a smaller budget. It is not a different codec and it is not a server. Cancel during either pass stops the job. A cancelled pass is not offered as a download.
What this page will not pretend
It will not promise a 15 GB file encodes on a phone. I have not timed that, and an old estimate is not a deadline. It will not add a watermark and then call the file clean. It will not upload the clip to finish the work when the tab runs out of memory.
It will not treat a Discord attachment cap as the only size that exists. Those caps live on the Discord page, because Discord publishes them and they change. This page takes the number you type. If you need the chat sizes, use that page. The encoder under both pages is the same one.
A silent clip is planned with no audio bits. A clip with sound keeps an audio track unless the browser cannot encode sound, in which case the page says so before you start. The start and end you typed apply to both tracks, so the sound does not keep playing after the picture has stopped.
23,750,000 is the aim inside a 25 MB cap
25 times 1,000,000 is 25,000,000. The encode budget is 95 percent of that, and 95 percent of 25,000,000 is 23,750,000. That is the number the bitrate is built from when the box says 25 and you keep whatever window you set. The status line still says the plan aims under 25.0 MB, because 25 is the cap you care about. 23.8 MB is the room the encoder is given.
On an 8 MB cap the same rule is 7,600,000 bytes. The budget code multiplies the cap by 0.95 and drops the fraction. It does not multiply by 1024. If your cap is a disk that counts kibibytes, this page will be a little more generous than that disk, and the file can still be under the number you typed.
The second pass, when the first file misses, uses 80 percent of the cap and will not go below 1,000,000 bytes. Eighty percent of 8,000,000 is 6,400,000. Eighty percent of a cap under 1.25 MB is clamped to 1 MB, so a tiny cap is not planned at a few hundred kilobytes of video. That clamp is why a one megabyte floor on the box matches the floor on the retry. I would rather show you the cap and the budget as two different numbers than let the encode aim at the cap and miss it by a header. The download line is the one that counts the bytes that actually landed.
Open the sample, then your own file
- Open the video compressor and click Use the sample.
- Read the plan. It names a cap and a picture size before you compress.
- Set the end earlier than the full duration if you only need a stretch. Picture and sound move together.
- Press Compress. Watch the percent. Cancel if you want to stop.
- Read the byte line after the encode. That is the size that landed.
- Download. The name ends in the cap you typed.
- If you copy the cap link, read it. One megabyte number. No video.
Then drop your own file in. If the plan says it will not fit, shorten the end or raise the cap. If the tab runs out of memory, the file never left the machine.
Last updated: September 22, 2026 | Reading time: 10 minutes
Written by Softery.io, which refused a 10 minute clip under 8 MB and accepted 20 seconds of it.