Video Trimmer

About this tool

Cuts a video down to the start and end time you choose, without re-encoding — the trimmed section is copied out as-is, so it's fast and lossless. Drag either handle on the slider, or type an exact value (down to the millisecond) into the boxes below it — both stay in sync, and each shows a live preview of the exact frame at that point. Runs entirely in your browser using ffmpeg.wasm, a WebAssembly build of the real ffmpeg; your video is never uploaded anywhere.

Why "no re-encoding" is the whole point. Video is normally compressed with periodic keyframes (complete images) and many in-between frames that are stored only as differences from nearby frames. Re-encoding decodes every frame, cuts, and recompresses from scratch — accurate to the exact frame, but slow, and it introduces a fresh generation of lossy compression on top of whatever the source already had. This tool instead uses ffmpeg's stream copy mode (-c copy), which copies the compressed video and audio data directly from the source into the output with no decode/recompress step at all — trimming a multi-gigabyte file typically takes seconds rather than minutes, and there's zero quality loss because no pixel is ever touched.

The trade-off: keyframe snapping. Stream copying can only start a new output file at an existing keyframe, since every frame between keyframes depends on the keyframe before it to be decodable at all. If your requested start time falls between keyframes (which are typically a few seconds apart), the actual cut point snaps to the nearest keyframe at or before that time — so the trimmed clip might start a fraction of a second earlier than exactly requested. The end point isn't affected the same way and trims precisely. For a genuinely frame-accurate start point, re-encoding is unavoidable, which is a deliberate trade-off this tool doesn't make in exchange for speed and zero quality loss.

Reading the live thumbnails. The frame preview above each start/end input isn't just a visual nicety — it confirms exactly which frame you're cutting at before committing, which matters more than it sounds given the keyframe-snapping behavior above: if the preview doesn't match what you expected, that's the actual keyframe-adjusted cut point ffmpeg will use.

Common uses: cutting a long screen recording down to just the relevant clip, trimming dead air from the start/end of a phone video before sharing it, extracting a highlight from a longer recording, or preparing a clip for a size-limited upload (a shorter clip at the same bitrate is a smaller file).

To sample frames across the full video into one overview image instead of cutting it, see the video sprite sheet generator or video thumbnail grabber for a single frame.

The ffmpeg engine (about 32MB) is only downloaded the first time you use this tool, not when the page loads.

Frequently asked questions

Why does my trimmed video start a fraction of a second earlier or later than I asked for?

Because this tool copies video data directly without re-encoding (for speed), a cut can only happen at an existing keyframe — the actual start may snap to the nearest keyframe before your requested time rather than landing exactly on it. This is a well-known trade-off of fast, lossless trimming; frame-perfect cuts would require re-encoding, which is slower.

Why did nothing happen for a while after I clicked trim?

The first click downloads and initializes the ~32MB ffmpeg engine, which takes a moment depending on your connection. After that first load, trimming itself is fast.

What format is the output?

The same container/format as your input file — since no re-encoding happens, the video and audio streams are copied through unchanged.

Is my video uploaded anywhere?

No — the entire process, including the ffmpeg engine itself, runs locally in your browser via WebAssembly. Nothing is sent to any server.

Why is this so much faster than a typical video editor's trim?

Most editors re-encode on export by default. This tool uses ffmpeg's stream-copy mode, which copies the compressed data directly with no decode/recompress step — the file size limits how long it takes to copy, not how long it would take to re-render every frame.

Will trimming reduce the video's quality?

No — because nothing is decoded or recompressed, the kept portion is bit-for-bit identical to that same portion in the original file.

Can I get a frame-perfect start point instead of the nearest keyframe?

Not with this tool, since that requires re-encoding (which trades away the speed and zero-quality-loss benefit of stream copying). If frame-perfect accuracy matters more than speed for a specific project, a full video editor with a re-encoding export is the right tool for that instead.