Compress a video
Decide what the encoder is allowed to spend, and the size follows from it.
How it works
A bitrate is a spending limit. Twelve hundred kilobits per second means the encoder may use twelve hundred kilobits to describe each second of picture, and no more than that. File size follows directly: rate multiplied by duration, divided by eight, is the output in bytes. The pipeline uses exactly that arithmetic to project a job before it starts, in `projectPeak`. Halve the figure and the file halves. Nothing about the picture is promised in return.
What the encoder does with the money is its own decision, and that is where quality actually lives. Handed fewer bits than a frame needs, it quantises more coarsely, merges neighbouring detail into flat areas, and holds still regions that were moving a little. The person picks the budget. The encoder picks the sacrifice.
The same figure is generous on one clip and cruel on the next
Two clips at 700 kbps can land in completely different places. Somebody talking in front of a plain wall gives the encoder almost nothing to pay for: the background is identical from one frame to the next and costs a few bits to say so, leaving the whole budget for the face. Grass in wind, foliage, rain, confetti, a crowd or a hand-held shot of anything textured changes every pixel of every frame, and there is no cheap way to describe that. The budget runs out part-way through the frame, and the result is the blocky smearing that gets called over-compressed.
Camera movement does the same thing for the same reason. A tripod shot of a busy street is cheap, while a slow pan across that street is expensive, because now every pixel moves. Where a clip has to be pushed hard, the material decides how hard it can go, and one test encode settles the question faster than any table of recommended rates.
Compressing something already compressed
Video off a phone, a camera, a screen recorder or a download has been through a lossy encoder once already. Encoding it again does not start from the scene. It starts from the first encoder's output, artefacts included, and the second encoder cannot tell a block edge it inherited from an edge that was really in the room. So it spends bits preserving damage. The size still obeys the arithmetic exactly. The picture does not: a second pass at half the rate looks worse than a first pass at half the rate would have looked.
Trim first, then compress
Bits spent on a section that is about to be deleted never reach the part being kept, so cutting before compressing is strictly better than the other order. Compressing first also runs two lossy passes over the footage that survives instead of one. `trim-video` makes the cut, and where the cut lands somewhere it can copy the frames straight across, it does not re-encode at all.
Frame rate is the other lever here and it is blunt. Halving 60 fps to 30 gives every remaining frame twice as many bits at the same total spend, which normally looks better. Going down to 15 makes motion visibly stutter, and only suits a screen recording of something largely static. Frame size is a third lever, and it belongs to `resize-video`.
Questions
Why did my file come out bigger than it went in?
Because the source was already spending less than the target you chose. The figure is a ceiling the encoder is allowed to reach, not a floor it must clear, and a clip shot at 500 kbps re-encoded against a 2,500 kbps budget has room to record its own artefacts in detail. Check the source's rate in a player or a file manager, then pick a destination below it, or type an explicit figure into the bitrate field.
Does anything about the file reach a server?
Nothing does. Frames are decoded and encoded by WebCodecs inside a Web Worker on your own machine. Open the Network tab before starting: every request listed is same-origin and fetches this page's own code, and no new one appears while the encode runs. There is no endpoint on this site that could accept a video.
What size will I actually get?
Multiply the total rate by the duration and divide by eight. A 90-second clip at 1,200 kbps of picture over a 128 kbps sound track spends 1,328,000 bits per second, so it lands near 14.2 MB. Screen recordings and static shots usually finish under the projection, because the encoder spends less than it was offered when there is nothing to describe. Nothing finishes over it.
Is a lower bitrate better than a smaller frame?
Up to a point. At 1,000 kbps a 1920×1080 frame at 30 fps gets 1,000,000 bits spread over 62,208,000 pixels, which is 0.016 bits each, and no encoder describes a full frame properly on that: the whole picture goes soft rather than only the difficult parts of it. Below that threshold, fewer pixels each described properly beats many described badly, and the frame should shrink instead. `resize-video` does that.