Video Cutter - Trim, Cut, Split & Merge Videos Online — Cut out unwanted parts, split a clip into multiple segments, or merge several video files into a single one. All processing is done locally in your browser , so your files are never uploaded to any server and your privacy is fully protected.
Supported input: Videos using open royalty-free codecs such as VP8/VP9/AV1/MPEG-4/FFV1 (WebM, MKV, MP4, MOV, AVI containers). Output format and codecs are selected below; every output is re-encoded locally in your browser.
First use loads an ~30MB video processing engine into the current browser. It is cached and reused afterwards, so please be patient.
🎥
Click to select or drag and drop a video file
Supports WebM, MKV, MP4, MOV, AVI and other common formats; under 500MB recommended
Trim / Cut: Keep only the part of the video between the start and end times (format HH:MM:SS or plain seconds, e.g. 00:00:05 or 5). The selected segment is re-encoded into a new file.
Split: Divide the video into multiple parts. Either list time points (comma separated, e.g. 00:00:10,00:00:20) or split into an equal number of parts. Each part is downloaded separately.
Merge: Add two or more video files, order them, then merge into one file. All inputs are re-encoded with the same settings, so mismatched codecs are handled, but for best results keep similar resolution and audio settings.
What are keyframes and GOPs? Why cutting video is harder than it looks
Cutting a video sounds like deleting a slice of bytes, but compressed video does not store complete pictures. A compressed stream is a chain that starts with a fully self-contained picture (a keyframe, the I-frame) followed by dozens of frames that only store what changed since the previous one. You cannot decode frame 47 unless you already decoded frames 1 through 46. That dependency chain — one keyframe plus all the frames that lean on it — is called a GOP (Group of Pictures). Cutting is therefore a negotiation with the GOP structure: cut on a keyframe and you can copy bytes; cut anywhere else and something must be rebuilt.
Five facts to anchor the rest of the page:
• I-frame (keyframe) = complete picture, decodable alone; P-frame = changes from the previous frame; B-frame = changes interpolated between two frames
• GOP = one keyframe plus its dependents; typical length: 1–2 seconds (at 30 fps that is 30–60 frames)
• keyframe cut = copy existing GOPs, instant and lossless, but the cut snaps to the nearest keyframe (up to a GOP-length of drift)
• frame-accurate cut = exactly the frame you picked, but the boundary GOP must be re-encoded
• size follows bitrate: a 60-second clip at 12 Mbps is 12×60/8 = 90 MB regardless of what is in the picture
I, P and B frames
The I-frame ("intra") is a complete JPEG-like picture of that moment; it is large but needs nothing else. The P-frame ("predicted") stores only the difference from the previous frame — a static camera shot makes P-frames almost free, which is why talking-head video compresses so well. The B-frame ("bidirectional") is predicted from both the previous and the next frame, catching objects that reveal then hide again; it is the cheapest to store but the hardest to edit, because decoding order no longer matches display order. Editing players hide this complexity; the file format does not.
Why a keyframe cut is instant and lossless
A keyframe cut selects whole GOPs and copies their compressed bytes into a new container — no decode, no re-encode, finished in about the time it takes to write the file. The price is precision: your requested in-point can only land where a keyframe actually exists. With a 2-second GOP at 30 fps (60 frames per GOP), the nearest keyframe can be up to 59 frames away, so the clip may start noticeably earlier or later than you marked. Streamers encode with 1–2 s keyframe intervals precisely so seeking stays responsive; surveillance footage with 10-second GOPs is infamous for "jumping" when scrubbed.
Why a frame-accurate cut must re-encode
Suppose the perfect start frame is a P-frame in the middle of a GOP. Its compressed bytes say "same as the previous frame, except..." — useless without the frames before it. To make it standalone, the cutter must decode the whole GOP up to that frame, promote your chosen frame into a new keyframe, and re-encode it (and everything after it until the next original keyframe). Only the boundary GOP pays this cost: the rest of the clip still copies byte-for-byte. That is why frame-accurate cutting is slower but only slightly lossier — one GOP gets a second compression pass, the rest is untouched.
Common misconceptions
"Cutting just deletes a section of the file." Almost no frame stands alone in a compressed stream; every cut point must be reconciled with the GOP structure first.
"Every cut re-encodes and costs quality." Keyframe cuts never re-encode. Even frame-accurate cuts only re-encode the single boundary GOP; everything copied after it is bit-identical.
"The cut point is exactly where I dragged the marker." In keyframe mode it snaps to the nearest keyframe; only frame-accurate mode honors the exact frame — and that is a mode choice, not a bug.
