Merge Overlapping Subtitles
Or paste subtitle text
Options
A space runs the two texts together on one line, which is what you want when the original file split a sentence across two cues. A line break stacks them, so the cue comes out as a two-line subtitle that stays on screen for the whole span.
Which frame rate the timings are counted in. On the format pages this is what MicroDVD needs, because it stores timing as frame numbers. On the frame rate pages it is the rate the file was timed against — the version the subtitles were made for — and the page's second box takes the rate of the video you are going to use them with. 23.976, 24, 25, 29.97, 30, 50, 59.94 and 60 are the common ones. Getting it wrong shifts the whole timeline, and on the frame rate pages it shifts it by a ratio rather than by a fixed amount.
Two cues overlap when the second one starts before the first one has finished. Players deal with that in different ways — some show both lines stacked, some show the second and hide the first, some flicker between them — so the same file looks different on two machines. This page takes the overlaps out of the player's hands and puts them in the file: each overlapping group becomes one cue that runs from the earliest start to the latest end, with both texts inside it.
The words all survive. What does not survive is each cue's own timing: after the merge there is one span where there were two, and the loss report says how many cues were absorbed so the change is on the page rather than in a diff. Nothing outside the overlapping groups moves at all, and the cue numbers keep the values they had, so a file whose cues 1 and 2 became one can carry on at cue 3.
Overlaps usually arrive from one of three places. A file retimed for another frame rate gets rounded twice and neighbouring cues creep into each other. A file assembled from two halves or two languages can have both tracks' cues running at the same time, which is fine on the timeline and not fine in one file. And a file converted from a format with screen positions — ASS with two lines placed top and bottom — was never written with one-cue-at-a-time in mind.
The alternative to this page is removing the overlaps instead, which pushes the later cue back so the two play one after another. That keeps the timing honest at the cost of screen time, and it is the right answer when two cues really are meant to be sequential. Merging is the right answer when they are meant to be read together — a line and its translation, a caption and the speech it describes — and the difference between the two is worth a minute of thinking before either is run. As everywhere on this site, nothing is uploaded: the file is read and written in this tab, and SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON and CSV all work.
Examples
Two cues sharing screen time
Input
1
00:00:01,000 --> 00:00:04,000
First.
2
00:00:03,000 --> 00:00:06,000
Second, starting early.
Output
1
00:00:01,000 --> 00:00:06,000
First. Second, starting early.
The second cue starts a second before the first one ends, so the pair becomes one cue spanning both. The overlapping second is no longer ambiguous — there is only one cue on screen between 00:00:03 and 00:00:04 — and both texts are still there, in the order they were in the file.
Cues that touch but do not overlap
Input
1
00:00:01,000 --> 00:00:02,000
First.
2
00:00:02,000 --> 00:00:03,000
Second, exactly touching.
Output
1
00:00:01,000 --> 00:00:02,000
First.
2
00:00:02,000 --> 00:00:03,000
Second, exactly touching.
One cue ending at the exact moment the next one starts is not an overlap, and this page treats it as a clean cut and changes nothing. That matters more than it looks: it is the commonest shape in a well-timed file, and a tool that merged it would turn a 900-cue episode into a single cue. If you do want those joined, that is the merge-by-gap page with its limit set to zero.
Three cues in a chain
Input
1
00:00:01,000 --> 00:00:03,000
One.
2
00:00:02,000 --> 00:00:05,000
Two.
3
00:00:04,000 --> 00:00:07,000
Three.
Output
1
00:00:01,000 --> 00:00:07,000
One. Two. Three.
Each cue overlaps the next, so the merges are not independent: the second cue's end is what the third cue is compared against, and all three become one cue. This is what a file looks like after a bad retime, and it is worth seeing that the text survives the collapse even though the individual timings do not.
Frequently asked questions
What counts as an overlap, and what is just a tight cut?
A cue overlaps when its start is earlier than the previous cue's end, by however little — one millisecond counts. A cue that starts at the exact millisecond the previous one ends is a tight cut, not an overlap, and this page leaves it alone. That test is what keeps a normal file safe here: almost every cue in a well-timed subtitle file begins exactly where the last one finished.
Why do subtitle files end up with overlapping cues?
Three common reasons. A frame rate conversion rounds both edges of every cue and neighbours creep into each other. A file built from two sources — two languages, two halves, a translated track laid over an original — has both sets of cues on the same timeline. And a file converted from ASS or another format that placed lines at different points on screen was written for a player that showed them at once.
Does merging overlaps move anything else in the file?
No. Cues that do not overlap are untouched, down to the millisecond, and their numbers are not rewritten either — the surviving cue in a merged group keeps the number it had, so an output that reads 1 and 3 is a file whose second cue was absorbed. What changes is only the groups themselves: one span where there were two or more, and one combined text.
Why merge overlapping cues rather than remove the overlaps?
Because the two cues belong together. Removing an overlap pushes the later cue back so the pair plays in sequence, which costs screen time and can leave a line cut off mid-sentence; that is right for two cues that were meant to follow each other. Merging keeps both texts visible for the whole span, which is right for a line and its translation, or a caption and the speech it describes.
What happens when three or more cues overlap each other?
They become one cue spanning from the earliest start to the latest end, compared cue by cue as the group grows: each new cue is tested against the end of the group so far. A chain of five overlapping cues therefore produces one cue with five lines' worth of text, and the report says four cues were absorbed — which is the number to check if the output looks shorter than you expected.
Which style is kept when two cues in different styles are merged?
The first one's. A cue can only carry one style, so an ASS or SSA file whose two overlapping cues use different styles comes out with the earlier cue's style and the report counts one item that could not come along. On a styled file it is worth reading the report before delivering: the merged cue will not burn the way the two originals did, and no amount of merging can change that.