Split a Long Video Into Parts, in Your Browser
By Mark Fulton · 2026-09-03 · 12 min read
Splitting a long video is trimming, repeated. Decide your boundaries, cut each part from its start second to its end second, save it, then do the next one. In a browser that means running a trimmer once per part, which takes about fifteen seconds per part once the numbers are written down. The catch nobody mentions is that a lossless cut cannot begin wherever you like. It has to begin on a keyframe, so the file for part two actually starts a few seconds before the second you asked for. Your footage is not lost and the boundaries are not wrong, but in some players those extra seconds show up and the parts look like they overlap.
Almost every answer to this question sends you somewhere else first. Install a desktop editor, open a terminal, or hand the file to a service that wants an upload and a queue slot. None of that is necessary for a job this mechanical. Below is the browser version, the arithmetic, what the cuts measurably do to a real one hour file, and what to do about the one behaviour that confuses people.
Why split instead of compress?
Compression and splitting solve different limits, and picking the wrong one wastes an hour.
Reach for splitting when the ceiling is per file:
- An attachment cap. Mail providers reject a single file over a fixed size no matter what the rest of the message looks like.
- A per file duration limit. Plenty of upload forms accept only clips shorter than some number of minutes.
- A processing ceiling. Browser tools, transcription services and phone apps all have a point where one enormous file will not go through, while four smaller ones sail past.
Reach for compression when the ceiling applies to the whole thing, when the recipient genuinely needs one continuous file, or when the footage is a screen recording of mostly static content, which shrinks a great deal for very little visible cost. There is a full walkthrough of that case in reducing screen recording file size, and the attachment maths specifically in compressing video for email.
The reason splitting is worth knowing is that it is free in quality terms. A lossless split copies the existing compressed data into new containers without decoding a single frame, so each part holds bit for bit what the original held. Compression cannot make that promise, because trading picture quality for bytes is what it is.
The two also stack, and the order matters. Splitting first and compressing the parts is far kinder to a browser than compressing an hour long file in one go, because each pass only ever holds fifteen minutes of video in memory. VidClip's free tier takes inputs up to 200 MB, so a large recording needs Pro before it will load at all, and past that the real limit is what your machine's memory can hold.
Where do lossless cuts actually land?
A compressed video is not a stack of complete pictures. Most frames are stored as differences from their neighbours, and only occasionally does the encoder write a full self contained image, called a keyframe. Everything after a keyframe can only be decoded by starting from that keyframe and applying the chain of changes.
That single fact decides everything about splitting. A copy based cut never decodes anything, so it has nowhere to begin except a keyframe. FFmpeg's own segment muxer documentation states the rule flatly: every segment starts with a keyframe of the selected reference stream, and adds that accurate splitting requires the input keyframes to fall on the exact times you want to split at. Keyframe spacing is an encoder decision you usually do not control, so in practice they do not.
To see how far off that puts things, I encoded a one hour test file and split it. The source is 3600 seconds of 1280x720 H.264 at 30 fps with AAC audio, 235 MB, produced by x264 at preset veryfast and CRF 26 with scene detection left at its default. It carries 513 keyframes. The gaps between them run from 0.87 seconds to 8.33 seconds, averaging 7.03. That spread is normal: the encoder writes a keyframe on a hard cadence and also whenever the picture changes enough to warrant one.
Splitting it into four fifteen minute parts with a plain stream copy, which is the same command shape the browser tool runs, the cuts landed here:
| Part | Requested start | Nearest keyframe at or before it | Distance | Extra frames in the file | Part size |
|---|---|---|---|---|---|
| 1 | 00:00 | 0.000 s | 0.000 s | 0 | 62.7 MB |
| 2 | 15:00 | 891.767 s | 8.233 s | 247 | 81.3 MB |
| 3 | 30:00 | 1797.767 s | 2.233 s | 67 | 55.7 MB |
| 4 | 45:00 | 2697.067 s | 2.933 s | 88 | 37.7 MB |
Part two is the interesting one. The nearest usable starting point was 8.233 seconds before the boundary I asked for, so the file it produced contains 27,249 video frames where a clean fifteen minutes is 27,002. Those 247 extra frames are exactly 8.233 seconds at 30 fps. Parts three and four carry 67 and 88 extra frames, again exactly matching their distances. The drift is not random and it is not a rounding error. It is the keyframe grid, and you can predict it from the file.
Two practical things fall out of that table. First, the error is always in one direction: a copy based cut can only reach backwards to a keyframe, never forwards, so parts start early and never late. Second, look at the sizes. Four parts of identical length came out at 62.7, 81.3, 55.7 and 37.7 MB. The largest is more than twice the smallest, because bitrate follows how much the picture is changing rather than the clock. If you are splitting to get under a size cap, equal time does not give you equal files, and the busiest stretch of the recording decides how many parts you actually need.
How do you split into equal parts without an app?
The arithmetic is one division. Take the running time in seconds, divide by the number of parts, and write the boundaries down before you touch anything. For a sixty minute recording split four ways that is 3600 divided by 4:
| Part | Start (s) | End (s) | Human boundaries |
|---|---|---|---|
| 1 | 0 | 900 | 00:00 to 15:00 |
| 2 | 900 | 1800 | 15:00 to 30:00 |
| 3 | 1800 | 2700 | 30:00 to 45:00 |
| 4 | 2700 | 3600 | 45:00 to 60:00 |
Then run the trimmer once per row. It takes a start second and an end second and gives back one clip, so four parts means four passes over the same file. There is no multi segment mode. In practice the four pass version is easier to keep straight anyway, because you see and name each part as it lands instead of fishing four files out of a zip afterwards.
Two habits make this painless:
- Type the numbers in seconds, not minutes. The fields take seconds, and converting once on paper beats converting four times under time pressure. 15:00 is 900. 30:00 is 1800. 45:00 is 2700.
- Rename each part the moment it saves.
talk-part-1.mp4throughtalk-part-4.mp4. Sorted alphabetically they stay in order, which is not true of whatever the download folder calls them by default.
The file is read straight off your disk into the page's memory through the browser's ordinary File API, processed by FFmpeg compiled to WebAssembly on your own processor, and written back out. Nothing is uploaded, so a large file costs you no transfer time and four passes over an hour long recording never queue behind anyone else's job. The one exception on the site is the transcription tool, which extracts and downsamples audio locally and then sends that audio out for recognition. It says so on its own page. Every other tool, splitting included, stays on your machine.
How do you avoid losing a frame between parts?
Start with the reassuring part: nothing falls between the parts. Despite every cut landing early, the four files from the test above present these ranges of the original.
| Part | Presents from | Presents to |
|---|---|---|
| 1 | 0.000 s | 900.066 s |
| 2 | 900.000 s | 1800.067 s |
| 3 | 1800.000 s | 2700.167 s |
| 4 | 2700.000 s | 3600.067 s |
Continuous, with a fraction of a second of overlap at each seam from frame boundaries. Not a frame is missing.
The way that works is worth knowing, because it explains the complaint people actually have. An MP4 can carry an edit list, a small instruction that tells the player which portion of the stored data to present and when to begin. The copy keeps the pre-roll from the keyframe so the first real frame has something to decode from, and writes an edit list saying "begin at 15:00". Part two therefore holds 27,249 frames and declares 27,002 of them. The 247 frames of pre-roll are in the file and are meant to be invisible.
Meant to be. Not every player and not every downstream tool honours edit lists. FFmpeg itself ships an ignore_editlist option on its MP4 demuxer precisely because ignoring them is sometimes what you want, and plenty of software ignores them without offering the choice. Feed part two to something in that category and it starts playing at 891.767 seconds instead of 900, showing you the last eight seconds of part one all over again. That is the overlap people report, and it is a playback and tooling question rather than a cutting mistake. The seam is correct, the file simply carries a little more than it advertises.
When the seams have to survive anything you point at them, there are three routes.
Re-encode the parts that matter. Frame precise trimming decodes and re-encodes the selection, so the exact start is baked into the frames themselves and no edit list is needed to hide anything. It costs real processing time and one generation of quality, which is tiny at a sane setting. On VidClip the free tier is frame precise by default, which is the mode you want here, and it carries a small corner watermark on video exports because re-encoded output is what a watermark can be drawn onto.
Cut generously, then fine cut. Take the part losslessly with a start a few seconds early, then run the frame precise trim on that fifteen minute part instead of on the hour long original. The re-encode then only touches a fraction of the footage and you keep the speed of the copy for the bulk of the work.
Put the keyframes where you want them. If you control the recording, set the encoder's keyframe interval to a value that divides into your intended parts, or force keyframes at the split points. This is the option FFmpeg's documentation points at, and it is the only one that makes a copy based split land exactly. It also has to be decided before you press record, which is why it rarely helps after the fact. There is more on the underlying mechanics in how keyframes work.
What's the fastest route for a long recording?
Work backwards from the constraint that made you want to split.
- A size cap, and no strong opinion about exact seams. Copy based parts, four passes, done in seconds regardless of how big the file is. The instant lossless path is the Pro mode on VidClip, because a stream copy has no re-encode step for a watermark to live in. If a part still lands over the cap, split into more parts before reaching for compression: splitting costs no quality and compression does. Remember that the busiest fifteen minutes will be the largest file, so size your parts against that stretch and not against the average.
- Exact seams, for chapters or a series that will be played by anything. Frame precise mode, one pass per part. Slower, exact, and it works on the free tier.
- A file too large for one browser pass. Split it losslessly first, then treat each part separately. Fifteen minutes of video is a much smaller thing for a tab to hold than an hour of it.
- A single continuous file that just needs to be smaller. Do not split at all. Compress it and keep it in one piece.
Pro is $4 a month billed $24 every six months, or $79 once for life. It removes the 200 MB input cap and the watermark, and adds the instant lossless paths. For a one off split of a smaller file, the free frame precise mode does the job without any of that.
Frequently asked questions
Can I split a video without re-encoding?
Yes, and it is the normal way to do it. Copying the compressed stream into new containers finishes almost instantly on a file of any size with zero quality loss, because nothing is decoded. The constraint is the one measured above: each part has to open on a keyframe, so the file starts a little before the second you asked for and relies on an edit list to present the right boundary. On VidClip the instant lossless path is the Pro mode. Free trims re-encode instead, which is what lets them cut exactly and also what lets them carry the small corner mark.
Why do my parts overlap slightly?
Because the file holds a few seconds of pre-roll from the keyframe before your split point, and whatever you are playing it in is ignoring the instruction to skip that pre-roll. In the test above, part two carried 8.233 seconds of it. A player that honours the edit list opens exactly on the boundary. One that does not opens early and repeats the tail of the previous part. Nothing is missing either way. If you need parts that behave identically in every player, re-encode them in frame precise mode, or force keyframes at your split points when you record.
How do I split a video on a phone?
The same browser workflow runs on a phone: open the trimmer, pick the file from your camera roll, enter the start and end seconds, save, repeat. What limits you is memory rather than software. A phone browser has far less headroom than a laptop, so a long high resolution recording may stall where a desktop would not. If it does, move the file to a computer for the split, or use more and shorter parts so each pass handles less at a time.
Is there a limit on how long a clip can be?
There is no duration limit in the tool itself. The limits that bite are file size and memory. The free tier accepts inputs up to 200 MB, Pro removes that cap, and above it the ceiling is whatever your browser can hold at once, which depends on your device rather than on us. A long recording at a modest bitrate can be perfectly fine while a short one at a very high bitrate is not, so file size is a better guide than running time.
Sources
- FFmpeg project, segment muxer documentation
- FFmpeg project, MP4 demuxer options, including
ignore_editlist - MDN Web Docs, File API
Measurements in this post come from a one hour 1280x720 H.264 test file I encoded and split for it, described in full above.