Video Trimmer

About Video Trimmer

This online video trimmer allows you to cut and trim video files directly in your browser. Simply select a video, choose the start and end time using the timeline or manual input, and trim your video. All processing happens locally for complete privacy.

Will trimming re-encode the video and reduce quality?

By default, browser-based trimmers using FFmpeg.wasm or the WebCodecs API often re-encode the trimmed portion so the cut points land exactly on the requested timestamps. Re-encoding loses some quality (small at high CRF, larger at low CRF) but lets you cut precisely between any two frames. To preserve original quality, use stream copy mode (FFmpeg -c:v copy -c:a copy), which is lossless and finishes in seconds — but the cut snaps to the nearest preceding keyframe instead of the exact requested time. For social media clips where pixel-perfect quality is not critical, re-encoding at CRF 18-20 is invisible to viewers. For archival or master files, stream copy with a small alignment tolerance is preferable to avoid generation loss.

Why does my trim start a few seconds late even though I picked the right time?

This is the classic keyframe-alignment issue. With stream copy, the trimmer can only start cutting at an I-frame (keyframe) because P-frames and B-frames depend on earlier frames for decoding. If your source has keyframes every 2-4 seconds (typical for web video), the cut will snap backward to the nearest keyframe, making the clip start up to 4 seconds before your requested time, or up to 4 seconds later if it snaps forward. To get frame-accurate cuts, switch to re-encoding mode, which decodes the surrounding frames and re-encodes a fresh keyframe at your exact timestamp. Alternatively, re-encode the source first with a keyframe every 1 frame (all-I-frame), then stream-copy trim — slow upfront, fast for many subsequent edits.

What's the best way to trim multiple clips from one long video?

For a small number of cuts (under 10), trim each segment separately and download. For many cuts, the most efficient workflow is: first transcode the source to an all-intra format (like ProRes, DNxHR, or H.264 with keyframe interval of 1) so every frame is a keyframe; this enables fast frame-accurate stream-copy trims for every subsequent cut. Then run a batch trim script with FFmpeg, listing start/end timestamps. The browser version of this tool processes one clip at a time, but you can chain trims by reloading the output as the new input. For nondestructive multi-clip editing, consider an Edit Decision List (EDL) or XML timeline workflow in a NLE — a trimmer is best for quick single cuts.

Does trimming an MP4 actually shorten the file size proportionally?

Roughly, yes — a 10-second clip from a 100-second 50 MB video will be about 5 MB. But not exactly proportional, for two reasons. First, container overhead (moov atom, codec config, metadata) adds a small fixed cost regardless of length, so very short clips have higher relative overhead. Second, video bitrate varies by scene complexity, so a 10-second action sequence may take much more space than a 10-second static interview. If you keep the same codec and stream-copy, you preserve original byte-accuracy on the kept portion. If you re-encode, you can choose a lower CRF to make the clip even smaller, or a higher CRF to keep visual quality on a complex segment that needs more bits.

Can I trim a clip with frame accuracy, like cutting exactly at frame 1247?

Yes, but the technique depends on what the video format allows. The most reliable method is to use re-encoding mode and specify the cut points in fractional seconds (1247 / fps), which forces the encoder to produce a fresh I-frame at your exact target. For best results, use the WebCodecs API where supported (Chrome 94+, Edge, Opera) — it gives true frame-level access without re-encoding the entire stream. With stream copy alone, frame-accurate cuts are only possible if every frame is a keyframe (all-intra source). Professional editors normally transcode footage to an intermediate all-intra codec (ProRes 422 or DNxHR HQ) before editing exactly to avoid this — they call this offline editing.

Why does the audio sometimes desync after trimming?

Audio/video desync after trimming usually comes from one of three causes. First, the audio codec (often AAC) has its own frame boundaries (1024 samples per AAC frame at 48 kHz = ~21 ms) that may not align with the video cut point, leaving a tiny offset that compounds in long edits. Second, the source has variable frame rate (VFR) video — many phone recordings and screen captures use VFR, and trimmers assuming constant frame rate (CFR) drift over time. Third, the source has separate audio delay metadata (edit lists in MP4) that the trimmer may strip or ignore. Fixes: convert source to CFR first (FFmpeg -r 30 or -vf fps=30), use trimmers that respect edit lists, or re-encode rather than stream-copy when precision matters.

How do I trim without uploading my video to a server?

Every cut in this tool happens locally in your browser using FFmpeg.wasm (a WebAssembly port of FFmpeg) or the native WebCodecs API. Your video file is read into a sandboxed memory buffer, processed by the WASM engine running on your CPU, and the result is written back to the browser for download. No bytes ever leave your device. You can verify this by opening DevTools and watching the Network tab — there are no upload requests during processing. This makes the tool safe for confidential content (legal evidence, medical recordings, internal corporate video) where uploading to a third-party server would violate privacy policies. The only network calls are loading the page and the FFmpeg.wasm binary (cached after first use).

What is the maximum video length or file size I can trim?

Browser-based trimming is limited by available RAM and the WebAssembly memory cap (4 GB max on 32-bit WASM, more on 64-bit WASM where supported). Practical limits: 1080p clips up to about 2-3 GB or 30-60 minutes work reliably on a desktop with 16 GB RAM; 4K or longer videos may freeze or crash the tab. For very large files, the recommended approach is to stream-copy trim (which doesn't decode the full video into memory) and avoid loading the entire file at once. As a workaround, you can split a huge source into chunks first, trim each chunk, then concatenate. Alternatively, use desktop FFmpeg for files over 5 GB — it streams from disk and isn't subject to browser memory constraints.