Trim Video
Drag the handles to the part you want and save it β with the picture copied through untouched, so nothing is lost. Your file never leaves the machine.
Why the handles, not two boxes
Choosing an in-point by typing a number means guessing, checking, and typing again. Dragging a handle while the frame under it updates is the same decision made once. The numbers are still there β you can type into them when you know exactly where the cut goes β but they follow the handles rather than replacing them.
Copy or re-encode
Video is not stored as a sequence of independent pictures. It is stored in groups that begin with one complete frame β a keyframe β followed by frames that describe only what changed. That is why a cut is not simply a matter of deleting bytes: everything after the in-point depends on what came before it.
Copying keeps those groups intact and hands them over as they are, which is why nothing is lost and why it is quick. When the in-point lands mid-group, the frames back to the previous keyframe come along for the ride β playback still starts where you asked, but the file carries them. Re-encoding writes only your selection, producing a smaller file at the cost of one generation of compression.
Either way it runs through the browser's own video pipeline, hardware-accelerated where the machine allows. No server is involved at any point: the page has no upload endpoint, and you can confirm it by watching the network tab or by disconnecting once the page has loaded.
Trimming is the first thing most footage needs. When a video needs cutting into several pieces instead of one, the splitter does that at the shot changes; to make a file smaller without changing its length, use the compressor.
Your file is read and re-encoded by your own browser. No request carries it anywhere β this page has no upload endpoint to send it to.
Questions
Is my video uploaded?
No. The browser decodes and re-encodes it locally through WebCodecs β the same pipeline it uses to play video. Nothing is sent anywhere, so there is no size limit imposed by a plan, no queue, and no watermark.
Does trimming lose quality?
Not in the default mode. "Same quality β no re-encode" passes the picture through untouched, so there is no generation loss and it finishes several times faster β measured at 0.2 seconds against 0.6 for a re-encode of the same clip. The trade is size: video is compressed in groups that begin at a keyframe, so when your in-point falls mid-group the file has to carry the frames back to the previous one. Playback still starts exactly where you set it, but the file can be larger than a re-encode of the same range.
When should I re-encode instead?
When you want the smallest file, or a different format. Re-encoding writes only the frames you selected, so a mid-group cut comes out considerably smaller β in testing, 4.1 MB against 6.7 MB for the same three seconds. It costs one generation of compression, which is not visible at the quality used here.
Can it trim to a target file size?
Yes β choose "Fit a size" and pick a limit, such as 10 MB for Discord or 25 MB for email. The needed bitrate follows from the length of your selection, so a shorter selection can hold more quality within the same limit. If the first pass misses, it corrects and re-encodes once.
Is the audio kept?
Yes, in sync, and trimmed to the same range. You can drop it deliberately with the "remove audio" box β useful when a clip is going somewhere the sound is not wanted, and it makes the file smaller.
Which files work?
MP4 and MOV with H.264, and WebM β whatever your browser can both decode and encode. Camera-native formats such as ProRes or raw usually cannot be opened by a browser at all; transcode a proxy first.
How long can the video be?
There is no hard cap, but everything happens in a browser tab, so memory is the real limit β the encoded result is held there before it is saved. Files up to a few hundred megabytes are comfortable on a normal laptop; very large ones are better trimmed in passes.
The other tools
Build this into your own project
Trimming video without re-encoding it β the same way this page does it, on the user's machine, with no server. Take the code, or hand the prompt to a coding agent.
import { Input, Output, Conversion, BlobSource, BufferTarget, Mp4OutputFormat, ALL_FORMATS } from 'mediabunny';
const input = new Input({ source: new BlobSource(file), formats: ALL_FORMATS });
const output = new Output({ format: new Mp4OutputFormat(), target: new BufferTarget() });
const conversion = await Conversion.init({
input, output,
trim: { start: 20, end: 35 },
// Omit `video` entirely to copy the track through; add
// { forceTranscode: true } to re-encode for a smaller file.
});
await conversion.execute(); Add "trim a video" to my project. It must run in the browser β no upload, no server.
Requirements:
- Use the "mediabunny" npm package (WebCodecs). Not ffmpeg.wasm: ~30 MB and needs SharedArrayBuffer,
which requires COOP/COEP headers that break third-party scripts.
- Offer two modes. Default: copy the video through untouched β pass NO video options to
Conversion.init and mediabunny will not re-encode. Measured 0.20s against 0.60s for a re-encode of
the same three seconds.
- Explain the trade honestly: video is stored in groups starting at a keyframe, so a copied cut whose
in-point falls mid-group carries the frames back to that keyframe. Playback still starts exactly
where the user set it, but the file is larger β 6.7 MB copied against 4.1 MB re-encoded in testing.
- The re-encode mode needs forceTranscode: true. Without it mediabunny correctly notices the
transcode is unnecessary and copies anyway, which makes the two modes identical.
- Give the user handles on a timeline with a live preview, not two number fields. Accept typed times
in any of 12.5, 1:04 or 1:04.5.
- Keep audio in sync and trimmed to the same range, with an option to drop it.
Reference implementation: https://life2film.com/tools/video-trimmer/
The engine is documented for agents, and every tool page is available as
markdown by adding .md to its address.