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, some desktop tools) |
Re-Encode Trim (how XConvert trims) |
|---|---|---|
| Quality loss | None — bit-for-bit identical frames | Visually none at the default preset (CRF 18 H.264 / CRF 17 HEVC) |
| Cut precision | Keyframe-aligned (cuts move to nearest I-frame) | Frame-accurate to the millisecond |
| Speed | Effectively instant | Proportional to clip length, resolution, codec |
| Audio sync | Preserved when stream copy is supported | Re-encoded from the same in-point, stays in sync |
| Codec change | Not possible — must keep source codec | Any supported 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 stream-copy trim in desktop tools 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. XConvert always re-encodes the kept segment at the visually-lossless default preset, so the cut lands exactly where you asked — on a specific word or beat if you want.
| 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.
Not visibly. Every trim re-encodes the kept section at the visually-lossless default preset (CRF 18 for H.264 / CRF 17 for HEVC), so the output is not mathematically identical to the source, but the re-encode is visually transparent for nearly all material — you'd need side-by-side comparison on a calibrated monitor to spot the difference. In exchange, the cut is frame-accurate instead of snapping to a keyframe.
With XConvert it shouldn't — the trim re-encodes the kept segment, so the output starts exactly at the timestamp you entered. The snap-back you're describing is keyframe alignment in stream-copy tools: MP4s compressed with H.264 or H.265 only store a full image (an I-frame, also called a keyframe) every few seconds, so a tool that cuts without re-encoding must rewind to the previous keyframe for the file to decode. Here the trimmer reconstructs the in-between frames, so no rewinding happens.
Yes — every trim is frame-accurate. Enter the start and duration in HH:MM:SS.sss and the encoder decodes from the nearest preceding keyframe up to your in-point, then writes the output starting exactly at your specified frame. Single-frame precision is the default behavior, no special mode needed.
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. Audio is re-encoded (default AAC) from the same in-point as the video, so the two stay aligned — you should see no audible drift even on hour-long source files. Note the output carries a single audio track: multi-language audio tracks and embedded subtitles are not guaranteed to carry over, so keep the source if those matter.
Don't count on it. The trim re-encodes the streams and rewrites the container, so top-level moov atom metadata — creation date, GPS coordinates on iPhone/Android footage, camera make/model — may or may not carry through, and chapter markers generally don't survive. If that metadata matters, archive the untouched source alongside the trimmed clip.
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 on our servers — there's no fixed upload cap on the file itself, only upload time over your connection. Processing scales with the length of the segment you keep, not the full source: trimming a 2-minute clip out of a 4K hour-long recording only encodes those 2 minutes.
Trimming runs on our servers 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.