Free tool · H.264 · Runs in your browser
Trim a video by timestamp
Short answer
Enter a start and an end, and the tool decodes the video and re-encodes only that range as H.264 and AAC, so the cut lands on your timestamps. Cutting 3 to 7 seconds of our 10 second test clip gave a file exactly 4.000 seconds long, for both picture and sound, at 1.04 MB against 13.53 MB for the whole clip. Nothing is uploaded.
Choose a video to check its duration.
- Selected length
- 00:00:15
- Requested range
- 00:00:00 → 00:00:15
- In seconds
- 0.00 → 15.00
The clip is decoded and re-encoded using the requested timestamps. Output boundaries follow the available frames and may differ slightly; this is not frame-exact editing. The video is re-compressed once.
Key takeaways
- Cuts land on the timestamps you give: 3 to 7 s gave 4.000 s, 0.4 to 9.6 s gave 9.200 s and 2.5 to 5.5 s gave 3.000 s, with the picture and the sound the same length each time.
- The range is re-encoded once. Against the same range of the source, the picture scored SSIM 0.9864, 0.9844 and 0.9866. Because the 10 second source runs at 10,827 kbps, the cuts were also far smaller: 1.04 MB, 2.44 MB and 0.80 MB.
- A stream copy cannot do this. The test clip has keyframes at 0.00, 0.87, 3.47, 6.87 s, so a copy cut from 3 s begins at the next keyframe: the copy's first picture came 0.466 s late, or the clip carried extra frames and ran 4.133 s instead of 4.
- The cut is not instant. The 4 s cut took 16.0 s to encode and the 9.2 s cut took 32.6 s in a headless run of the same engine, and the FFmpeg wiki warns that a timestamp placed after the input is reached by decoding everything before it.
- Timestamps can be seconds (90), minutes and seconds (1:30), or hours, minutes and seconds with a decimal part (00:01:30.5). Files up to 100 MB are accepted.
What the tool does to your file
The tool reads the length of your file in the browser first, so it can reject a start that is past the end and cap an end that is too long. It then runs one ffmpeg command with your two timestamps.
The timestamps come after the input on the command line. The FFmpeg wiki describes that placement as output seeking: the input is decoded and discarded until the start is reached, which is slow, and the drawback is that the bigger the offset, the longer it takes. The benefit is an accurate cut.
| Setting | Value | What it means |
|---|---|---|
| Cut points | -ss start -to end, after -i, three decimals | Millisecond resolution, reached by decoding |
| Video | H.264 (libx264), yuv420p, preset veryfast | Quality target CRF 23, the encoder default |
| Audio | AAC | Re-encoded with the encoder default bitrate |
| Validation | End must come after start; start must be inside the file | An end past the file length is cut back to the length |
Measured: three cuts
Measured on a 10 second 1920 × 1080 excerpt of Big Buck Bunny (CC BY 3.0, Blender Foundation) with a speech soundtrack. It is an animated film, not camera footage, so the sizes of camera video will differ. The tool's own ffmpeg arguments ran on the same single-thread WebAssembly engine your browser downloads; times are from a headless run and your device will differ.
SSIM compares each output with the same range of the source; 1.0 would be identical.
| Range | Output length | Picture and sound length | Output size | SSIM against the source range | Encode time |
|---|---|---|---|---|---|
| 3 s to 7 s | 4.000 s (expected 4) | 4.000 s and 4.000 s | 1,039,791 bytes (1.04 MB) | 0.9864 | 16.0 s |
| 0.4 s to 9.6 s | 9.200 s (expected 9.2) | 9.200 s and 9.200 s | 2,442,296 bytes (2.44 MB) | 0.9844 | 32.6 s |
| 2.5 s to 5.5 s | 3.000 s (expected 3) | 3.000 s and 3.000 s | 802,140 bytes (0.80 MB) | 0.9866 | 12.0 s |
The Trim a video tool on a 10 second 1080p clip, 13.53 MB as published.
Every cut started at 0 on its own timeline, and picture and sound ended together to the millisecond.
Why a stream copy cannot cut where you ask
Most fast cutters copy the compressed video instead of re-encoding it. That is lossless and instant, but a copied video can only start on a keyframe, because every other frame depends on the frames before it. The FFmpeg wiki says that placing the start before the input makes ffmpeg seek by keyframe, and that libx264 uses a keyframe interval of 250 frames by default, one every 10 seconds at 25 fps.
Our clip has keyframes at 0.000, 0.867, 3.467, 6.867 seconds. Cutting from 3 seconds with a copy had two outcomes, both measured below. Neither is a 3 to 7 cut.
| Method | Length | First picture at | Size |
|---|---|---|---|
| This tool (re-encode) | 4.000 s | 0.000 s | 1,039,791 bytes |
| Stream copy, start after the input | 4.066 s | 0.466 s (no picture until the next keyframe at 3.467 s) | 4,278,448 bytes |
| Stream copy, start before the input | 4.133 s | 0.000 s (starts at an earlier keyframe) | 7,871,907 bytes |
FFmpeg's documentation explains the second result: when doing stream copy, the segment between the seek point and the position is preserved rather than discarded. The copies kept the full 10,827 kbps of the source, which is why they are several times larger than the re-encoded cut. If you need the original quality untouched and can accept a cut on a keyframe, a copy is the right tool; for an exact cut, re-encoding is.
Timestamps the tool accepts
The text boxes accept seconds, minutes and seconds, or hours, minutes and seconds, with an optional decimal part. These are the results of the tool's own parser:
| You type | The tool reads |
|---|---|
| 90 | 90 s (00:01:30) |
| 1:30 | 90 s (00:01:30) |
| 00:01:30 | 90 s (00:01:30) |
| 00:01:30.5 | 90.5 s (00:01:30.500) |
| 1:30:00 | 5400 s (01:30:00) |
| 1:75 | not accepted |
| 1.5.2 | not accepted |
Minutes and seconds must each be below 60, and a decimal part is read as a fraction of a second. The cut itself is written with three decimals, so the resolution is a millisecond, but the video can only be as exact as its frames: at 30 frames per second a frame lasts 33 ms.
Habits that keep the quality
- Trim from your original. A second trim of a trimmed file is another re-encode on top of the first.
- Expect large offsets to take longer. The tool decodes the whole video up to your start, so a cut starting at minute 20 of a long file takes longer than one at second 20.
- Use timestamps, not frame numbers. For frame-numbered editing use a timeline editor.
- Compress after you trim, not before. A shorter file is quicker to compress.
Free tools:Compress a videoCrop a video preciselyMerge videosWhat is a keyframe?
Questions people ask
How do I trim a video without losing quality?
The tool re-encodes the range once, so there is a small loss: SSIM 0.9864 against the source on our clip. Only a stream copy is lossless, and it can only cut on a keyframe, which on our clip meant a start 0.466 s late.
Is the cut frame accurate?
It follows your timestamps to the millisecond, and picture and sound ended together on all three of our cuts. The video can only be as exact as its frames, 33 ms at 30 fps. It is not a frame-numbered editor.
Why is the trimmed file smaller than the original?
The tool writes H.264 at quality 23, which on our 10,827 kbps clip came out at about 2,080 kbps. A source that is already lightly compressed can come out larger.
Why is trimming slow for a late start?
The tool puts the start after the input, so ffmpeg decodes and discards everything before it. The FFmpeg wiki says the bigger the offset, the longer it takes.
What timestamp formats work?
Seconds (90), minutes and seconds (1:30), and hours, minutes and seconds (00:01:30), each with an optional decimal part. Minutes and seconds must be below 60.
Does the video leave my device?
No. The file is read and processed in your browser. It accepts files up to 100 MB, and the first run downloads an engine of about 30 MB once per visit.
What if my end is past the end of the video?
The tool cuts it back to the length of the file. A start past the end is rejected with a message.
Related
Sources and how we checked
- FFmpeg wiki: Seeking (read 2026-10-09)
- FFmpeg Documentation: ffmpeg (read 2026-10-09)
- FFmpeg wiki: Encode/H.264 (CRF and presets) (read 2026-10-06)
Reviewed October 9, 2026. The measurements ran the tool’s own ffmpeg arguments on the same single-thread WebAssembly engine your browser downloads. The script, the results and the saved documentation are in data/seo/hub/evidence/2026-10-09/tools.