Trim MP4 video by setting start time and duration. Remove unwanted sections from recordings, create social media clips, and extract highlights.
Process files in seconds with our optimized servers
Set exact start and end points with frame accuracy
Maintain original quality with smart re-encoding
HH:MM:SS.sss (or seconds) and the duration of the clip you want to keep. The output runs from start for duration seconds — millisecond precision is supported, and you can preview the in/out points before processing.MP4 (MPEG-4 Part 14) is the dominant delivery container for H.264 and H.265 video — it plays natively on every modern browser, every iPhone and Android since 2010, and every TV and game console you'll meet in the wild. Trimming an MP4 removes unwanted footage at the start, end, or middle without re-shooting and without exporting from a heavyweight editor. Typical reasons people trim:
If you also want to change container or codec, do MP4 to MOV or MP4 to GIF after trimming. For a different output container, see Trim MOV. For dropping file size after trimming, see Compress MP4. The sibling tool Cut MP4 uses the same engine — pick whichever wording matches what you searched for.
| Property | Stream-Copy Trim (-c copy) |
Re-Encode Trim |
|---|---|---|
| Quality loss | None — bit-for-bit identical frames | Slight; minimal at CRF 18–20 |
| Cut precision | Keyframe-aligned (cuts move to nearest I-frame) | Frame-accurate to the millisecond |
| Speed | Effectively instant — typically seconds even for 4K | Slower; depends on length, resolution, codec |
| Audio sync | Preserved when stream copy is supported | Re-muxed and re-synced |
| Codec change | Not possible — must keep source codec | Required if changing codec, resolution, or bitrate |
| Typical keyframe drift | 0–10 seconds depending on GOP length | None |
x264 and x265 default to a maximum keyframe interval of 250 frames (about 10 seconds at 25 fps and a little over 4 seconds at 60 fps), with the encoder free to place additional keyframes at scene changes. That's why a pure stream-copy trim may start a few seconds earlier than the timestamp you typed — it snaps to the nearest preceding I-frame because P- and B-frames depend on previous keyframes for their data. If you need frame-accurate edits (e.g., to cut on a specific word or beat), re-encoding is the only way. Most XConvert trims default to re-encode with a sensible CRF so the cut lands exactly where you asked.
| Codec | CRF range (lower = better) | Visually transparent | Notes |
|---|---|---|---|
| H.264 (libx264) | 0–51 (default 23) | 18–20 | Universally supported; safest pick for MP4 |
| H.265 / HEVC (libx265) | 0–51 (default 28) | 22–24 | ~50% smaller than H.264 at equal quality; iOS and modern Android decode it natively |
| AV1 (libaom-av1, libsvtav1) | 0–63 (default ~30) | 25–32 | Newest royalty-free codec; best compression but encoder is slower; YouTube and Netflix re-encode to AV1 server-side |
| VP9 (libvpx-vp9) | 0–63 (default 31) | 28–33 | WebM's native codec; widely supported on the web |
| MPEG-4 (Xvid / DivX) | 1–31 qscale (lower = better) | 2–4 | Older but still useful for legacy DVD players and very old phones |
CRF (Constant Rate Factor) targets a perceptual quality level and lets bitrate vary across the clip. Constant bitrate (CBR) holds a fixed bits-per-second — useful when a delivery platform wants a known size budget, less efficient quality-per-megabyte than CRF for almost any creative video.
Only if the trim re-encodes. A pure stream-copy trim copies the source frames bit-for-bit and the output is mathematically identical to the source for the section you keep. A re-encode at default settings (CRF 23 for H.264, CRF 28 for H.265) is visually transparent for nearly all material — you'd need side-by-side comparison on a calibrated monitor to spot the difference, and that difference is the encoder's, not the trim's.
That's keyframe alignment. MP4s compressed with H.264 or H.265 only store a full image (an I-frame, also called a keyframe) every few seconds; everything in between is a delta against previous frames. If your trim is set to stream-copy mode and your "start" lands inside one of those gaps, the cut snaps back to the previous keyframe so the resulting file can decode. To land exactly on your chosen frame, allow re-encoding — the trimmer will reconstruct the in-between frames from scratch.
Yes — pick re-encode trim (the default in XConvert when you change codec or quality settings) and enter the start and duration in HH:MM:SS.sss. The encoder will decode from the nearest preceding keyframe up to your in-point, then write the output starting exactly at your specified frame. This is slightly slower than stream-copy but gives single-frame precision.
Not in a single output file from this tool — each trim produces one continuous output. If you need to remove a middle section, trim twice (once for the before, once for the after) and join the two with a video joiner. For multi-segment edits with crossfades or transitions, use a non-linear editor.
Yes. In stream-copy mode the audio stream is copied untouched and the container's timing references keep video and audio aligned. In re-encode mode, audio is re-encoded (default AAC) and re-synced; you should see no audible drift even on hour-long source files. Multi-language audio tracks and embedded subtitles are preserved.
Top-level moov atom metadata — creation date, GPS coordinates on iPhone/Android footage, camera make/model — is carried through both stream-copy and re-encode trims. Chapter markers are preserved by stream-copy and dropped by some re-encode paths; if chapters matter, use stream-copy mode.
If you re-encoded to a higher bitrate or a less efficient codec than the source, the output can be larger per-second than the input despite being shorter overall. Check that your CRF or bitrate target is not below the source bitrate — for a 4K H.264 source averaging 50 Mbps, picking a CRF of 18 may write a near-lossless output that's comparable in size to the original. Drop to CRF 23–26, switch to H.265, or set a target file size to shrink the result.
Yes. Trims run in your browser session — there's no fixed upload cap on the file itself, only the resources the browser and machine can spare. A 4K hour-long source is happiest with the stream-copy path (no decode/re-encode) and finishes in tens of seconds rather than minutes. If you're re-encoding 4K to H.265, expect roughly real-time or faster on a modern laptop.
Trimming runs in your browser session and files are deleted after the session ends. No account, no watermark, no per-file or per-day count caps, and no hidden Pro tier gating duration or resolution.