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.

What does the 'Web-optimized MP4 (faststart)' toggle do, and which CRF do the quality presets use?

Faststart moves the MP4/MOV moov atom (the index that tells a player where every frame lives) from the end of the file to the front. Without it, a trimmed clip uploaded to a website or CDN cannot begin playing until the whole file has downloaded, which breaks progressive playback, social embeds, and even this tool's own in-page preview. With the toggle on (default) we pass FFmpeg -movflags +faststart on any MP4/MOV re-encode so the clip streams instantly. It only applies when re-encoding (High/Medium/Low) — stream Copy preserves the source's existing atom layout untouched. The re-encode presets map to fixed H.264 CRF values: High = CRF 18 (visually lossless, larger file, 192k AAC audio), Medium = CRF 23 (the x264 default, balanced, 128k AAC), Low = CRF 28 (smaller file, visible compression on detailed footage, 96k AAC). Lower CRF means higher quality and larger size; each +6 roughly halves the bitrate. The accuracy badge next to the toggle tells you whether your current settings produce a frame-accurate cut (any re-encode preset) or a keyframe-aligned cut (Copy).

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?

This tool enforces a 100 MB per-file limit in the browser. That cap exists because FFmpeg.wasm loads the entire input into a sandboxed WebAssembly heap, and re-encoding holds both the source and the output in memory at once; staying under 100 MB keeps the single-threaded core stable on phones and modest laptops without freezing or crashing the tab. In theory WebAssembly allows up to 4 GB on 32-bit WASM (more on 64-bit builds), and desktop browsers with 16 GB RAM can handle larger clips, but reliability drops fast above a few hundred megabytes — so we cap at 100 MB rather than let large files crash mid-trim. For bigger sources, the recommended workflow is to stream-copy trim (which avoids decoding the whole video) or split the file into chunks, trim each, then concatenate. For files well over 100 MB, desktop FFmpeg is the better tool — it streams from disk and is not bound by browser memory limits.