Does the merger pair cue 12 with cue 12, or does it use the timings?

Neither, because it does not pair at all. Overlay mode concatenates the two cue lists and sorts the result by start time; append mode adds an offset to the second list and puts it after the first. In both cases every cue from both files survives as its own separate cue, keeps one language, and is renumbered in the output. Four English cues and three French ones give seven cues, not four combined ones, and the count shown under the input box says so before you scroll. Index matching would be wrong here anyway — the counts diverge the first time a translator joins two short lines into one — and time-overlap matching, which is the correct approach, needs a threshold that this tool has no field for. What overlay does give you, when both tracks were spotted from the same master, is a file in which each pair of cues sits adjacent, because equal start times sort together and the order the cues were read in is preserved.

I merged 4 English cues with 3 French ones and got 7. Is that a bug?

No, it is what interleaving means, and seven is the arithmetically correct answer for an operation that combines nothing. The tool is doing exactly what it says it does — merging two files into one, renumbered — and "merging files" is not the same operation as "merging cues". If you expected four cues each holding two languages, you were expecting a pairing step that this tool does not contain. Read the seven-cue output as an interleaved reading track rather than a bilingual one: at any moment where the two source tracks had the same timing you will see the two lines follow each other, which is usable for study; at any moment where the timings differ, one language will simply appear alone. If you need a true bilingual file, the two texts have to end up inside one cue body separated by a line break, and you get there either in a text editor or through the CSV round trip, which now carries a two-line cue back intact.

What does a player do with two cues that occupy exactly the same window?

There is no answer that holds everywhere, and that is a fact about the format rather than a gap in this article. SubRip has no specification: the Library of Congress format description lists no specification document at all and records the format as only partly documented and not well standardised. Nothing therefore defines what a renderer should do when two entries claim the same interval. Some stack them as separate lines, some show only one, some drop one without a message, and the same file can behave differently in a desktop player, a phone app and a browser because those use different rendering paths. Even the container does not help: when SubRip is muxed into Matroska the start time becomes the block timestamp and the length becomes a block duration, and because there are no general settings for the codec there is nowhere to record a preference. Test a thirty-second sample in the player you will actually use, and test it there rather than somewhere convenient.

Can I put the original at the top of the screen and the translation at the bottom?

Not from an SRT file, because SubRip has no positioning of any kind. The formatting the original program supported was limited to bold, italic, underline and colour, derived from HTML tags, and none of it addresses placement; the Matroska container confirms the same shape from the other side, storing an SRT cue as text plus a timestamp plus a duration and leaving the codec's private data empty, because there are no general settings to record. The {\an8} override you sometimes see in ripped files belongs to a different format and works only in players that happen to honour it. What you can control is the order of the lines inside one cue, which means putting both languages in the same cue and accepting whatever placement the player chooses for the block as a whole. If placement genuinely matters, use WebVTT instead: its cue timings line takes a settings list including alignment, line and position, and it defines REGION blocks for scroll areas — real, specified placement rather than a convention.

When is append mode the right choice, and what is the trap in it?

It is the right choice for one job: a film that arrives as two video files with one subtitle file each. The tool finds the largest end time in the first file, adds the gap you enter in seconds, and adds that total to every timestamp of the second file, so the second part starts cleanly after the first. The trap is that it adds to the second file's existing timestamps instead of replacing them. That is correct when the second file is timed from zero, which it usually is when the two parts were subtitled separately. It is wrong when the second file was cut out of a longer one and still carries its original positions: tested with a second file whose first cue sat at 00:10:00, appending after a 12-second first part with a 1-second gap put it at 00:10:13 rather than 00:00:13, leaving a ten-minute silence in the middle of the result. The fix takes thirty seconds — shift the second file by minus its own first timestamp before merging — but nothing warns you, so check the first cue of the second half in the output.

Merging Two Subtitle Tracks Into a Bilingual Version: What Actually Happens to the Cues

Published 8/5/2026 · 15 min read · Developer tools

Daniel Okonkwo — Front-end developer and tech writer at OneKitly

Web performance · File formats

Checked against 4 sources

View profile →

In short

This merger does not pair cues at all, and knowing that before you start saves an hour. It offers two modes. Overlay concatenates both cue lists and sorts the result by start time, so nothing is combined: four English cues and three French ones produce seven separate cues, each still carrying one language. Append shifts the whole second file to begin after the end of the first plus a chosen gap, which is for joining the subtitles of two video parts, not two languages. Neither mode matches by index and neither matches by time overlap — the two strategies a bilingual merge would need. That matters because the cue counts almost never agree: a translator who turns two short English lines into one French sentence has already broken the index correspondence, and from that cue onward the numbering of the two files diverges permanently. Overlay is still useful when both tracks were timed from the same master, because equal start times keep each pair adjacent and the sort preserves the order they were read in, so the first file's line comes first. But the moment one track leads by even forty milliseconds on a given line, that pair flips, and your two languages stop appearing in a consistent order. What overlay never produces is one cue holding two lines. If that is what you want, the two languages have to be joined inside a single cue's text, which is a text edit rather than a timing operation — and SubRip has no positioning of any kind, so where the lines land on screen is decided by the player, not by your file.

Cue 12 of the English track is not cue 12 of the French one, because translators split and join sentences differently. Two strategies exist for pairing them; this merger uses neither — it interleaves. Here is what that gives you and when it is good enough.

Why cue 12 is not cue 12

Take twelve seconds of dialogue. In English it is four cues: "I told you." / "I told you twice." / "And you did it anyway." / "That is the part I mind." The French translator collapses the first two into one line that fits comfortably on screen, and delivers three cues covering the same twelve seconds. From that point on, English cue 3 is French cue 2, English cue 4 is French cue 3, and every subsequent divergence — a line split for reading speed, two lines joined because the target language is shorter — moves the correspondence again. Nothing in either file records that this happened.

So a bilingual merge has to decide, cue by cue, which line of one file belongs with which line of the other, and there are only two honest ways to do it. Matching by index is instant and correct until the first divergence, after which it is confidently wrong for the rest of the film — and the failure is invisible in a text editor, because both files still look perfectly well formed. Matching by time overlap is the real answer: two cues belong together when their intervals intersect by more than some threshold. It needs that threshold, because a translator's cue often starts a fraction later, and because a long cue in one language can overlap two short ones in the other, which forces a choice between pairing it with the longer overlap and pairing it with both.

What this merger does instead: interleave and concatenate

Overlay mode takes the cue list of the first file, takes the cue list of the second, puts them end to end and sorts the whole thing by start time. That is all it does. No cue is ever combined with another, no text is joined, no threshold is applied. Run it on the four-and-three example above and it returns seven cues, numbered 1 to 7, alternating between the two languages wherever the timings alternate. The count under the box tells you as much before you scroll: seven, not four.

That is not useless, and it is worth being fair about when it works. If both tracks were timed from the same master — which is the normal case for a professionally subtitled release, where the translator works from the original spotting list — the start times will often be identical, and identical start times keep each pair adjacent in the output. The sort preserves the order in which the cues were read, so the first file's line comes first in every tie, and you get a file that alternates language reliably. Tested on two tracks with identical timings, four cues each, the output is eight cues in strict first-file-then-second-file pairs.

The reliability ends as soon as the timings are merely close instead of equal. Give the French track a forty-millisecond later start on every line and the pairs stay adjacent, still English first. Give it a forty-millisecond earlier start on one line and that pair flips: the French line is now cue 1 and the English is cue 2, while the rest of the file keeps the other order. Reading a bilingual track whose language order changes without warning is worse than reading two separate files, so before you use overlay output for study, check a handful of pairs across the film rather than only the first one.

Append mode is a different tool for a different job: joining the subtitles of a film that arrives in two files. It computes the largest end time in the first file, adds the gap you enter, and adds that total to every timestamp of the second file. The trap is that it adds to the second file's own timestamps rather than replacing them. If your second part is already timed from zero, everything is right. If it was cut from a longer file and its first cue sits at 00:10:00, you get 00:10:13 instead of 00:00:13 — the tool tested exactly that and produced a ten-minute hole. Re-zero the second file first with the time-shift tool, then append.

Two cues in the same window, and why nobody can tell you what happens

Overlay output routinely contains two consecutive cues with identical start and end times — that is exactly what a bilingual pair looks like once the tool has finished. What a player does with that is not specified anywhere, because SubRip has no specification to specify it in. The Library of Congress lists no specification document for the format at all. The Matroska container, when it ingests SubRip, keeps the start time as the block timestamp and the duration as a block duration and nothing else: there are no general settings for the codec, so the container carries the text and the timing and has no field in which to record a preference about overlaps.

In practice players differ, and the only reliable procedure is to test yours on a thirty-second sample before committing to a full film. Some renderers stack simultaneous entries as separate lines; some show the last one loaded and hide the other; some drop one silently. None of them is wrong, because there is nothing to be wrong about. Do not carry an assumption from a desktop player to a phone, a television app or a web page: they use different rendering paths, and a bilingual file that looks correct on a laptop can show a single language on a set-top box.

The related question — where each language appears on screen — has a shorter answer: you cannot control it from an SRT file, because SubRip has no positioning at all. The original program's formatting was limited to bold, italic, underline and colour derived from HTML tags, and nothing in the format addresses placement. WebVTT is the opposite: its cue timings line can carry a settings list with alignment, line and position, and it defines whole REGION blocks for scroll areas. If placement matters to your bilingual track, that is a reason to work in WebVTT and not in SubRip.

How to actually get two languages into one cue

The result you probably want is one cue per moment holding two lines, the original above and the translation below. That is a text operation: the two strings have to end up in the same cue body, separated by a line break. The tempting route on this site is the spreadsheet round trip — export the first track with the SRT to CSV converter, paste the second language into a column alongside, build a combined text column, and rebuild the file with the CSV to SRT converter. That route works end to end, and the next paragraph is about why it can be trusted with a whole film.

Both halves are correct. A cue containing a line break is written as a quoted CSV field with a real newline inside it, which is the form RFC 4180 describes and the one a spreadsheet opens as a single cell; the CSV to SRT converter reads the file as CSV records rather than as text lines, so a newline ends a record only when it falls outside the quotes. Tested with a hand-built bilingual cue, "I told you." over "Je te l'avais dit.", the round trip returns both lines inside the same cue, and a file mixing one-, two- and three-line cues comes back byte-identical to the original.

So the practical recipe is this. Export the first track, paste the second language into a spare column, and build a combined text column that puts a real in-cell line break between the two — Alt+Enter in Excel on Windows, your spreadsheet's own shortcut elsewhere, and not a typed backslash and n. Paste the four columns back into the CSV to SRT converter and the cues come out with the original above and the translation below. Keep the index column while you work: the importer rebuilds in its order, so a sheet you sorted along the way still gives you a file in time order. The one thing to watch is the spreadsheet rather than the tools — it may retype a timestamp column the moment you open the file, so import rather than double-click and set the two time columns to Text. If you would rather not involve a spreadsheet at all, pasting the two tracks side by side in a text editor and joining them by hand is still the shortest route for a handful of cues.

Four ways to combine two subtitle tracks, and what each one gives you from 4 English cues and 3 French ones
Strategy	How it decides what goes with what	Result on the example	Available here?
Match by index	Cue n of one file with cue n of the other	Correct until the counts diverge, then wrong to the end	No
Match by time overlap	Intervals that intersect beyond a chosen threshold	3 or 4 combined cues, depending on the threshold	No
Interleave (this tool, overlay mode)	Both lists concatenated, then sorted by start time	7 separate cues, one language each, pairs only where starts match	Yes
Concatenate (this tool, append mode)	The second file is pushed past the end of the first, plus a gap	7 cues playing one after the other — for two video parts, not two languages	Yes
Pair by hand in a text editor	You decide, reading both files side by side	4 cues, each holding two lines — the bilingual result	Not automated by the merger — do it in an editor, or via the CSV round trip

Frequently asked questions

Does the merger pair cue 12 with cue 12, or does it use the timings?: Neither, because it does not pair at all. Overlay mode concatenates the two cue lists and sorts the result by start time; append mode adds an offset to the second list and puts it after the first. In both cases every cue from both files survives as its own separate cue, keeps one language, and is renumbered in the output. Four English cues and three French ones give seven cues, not four combined ones, and the count shown under the input box says so before you scroll. Index matching would be wrong here anyway — the counts diverge the first time a translator joins two short lines into one — and time-overlap matching, which is the correct approach, needs a threshold that this tool has no field for. What overlay does give you, when both tracks were spotted from the same master, is a file in which each pair of cues sits adjacent, because equal start times sort together and the order the cues were read in is preserved.
I merged 4 English cues with 3 French ones and got 7. Is that a bug?: No, it is what interleaving means, and seven is the arithmetically correct answer for an operation that combines nothing. The tool is doing exactly what it says it does — merging two files into one, renumbered — and "merging files" is not the same operation as "merging cues". If you expected four cues each holding two languages, you were expecting a pairing step that this tool does not contain. Read the seven-cue output as an interleaved reading track rather than a bilingual one: at any moment where the two source tracks had the same timing you will see the two lines follow each other, which is usable for study; at any moment where the timings differ, one language will simply appear alone. If you need a true bilingual file, the two texts have to end up inside one cue body separated by a line break, and you get there either in a text editor or through the CSV round trip, which now carries a two-line cue back intact.
What does a player do with two cues that occupy exactly the same window?: There is no answer that holds everywhere, and that is a fact about the format rather than a gap in this article. SubRip has no specification: the Library of Congress format description lists no specification document at all and records the format as only partly documented and not well standardised. Nothing therefore defines what a renderer should do when two entries claim the same interval. Some stack them as separate lines, some show only one, some drop one without a message, and the same file can behave differently in a desktop player, a phone app and a browser because those use different rendering paths. Even the container does not help: when SubRip is muxed into Matroska the start time becomes the block timestamp and the length becomes a block duration, and because there are no general settings for the codec there is nowhere to record a preference. Test a thirty-second sample in the player you will actually use, and test it there rather than somewhere convenient.
Can I put the original at the top of the screen and the translation at the bottom?: Not from an SRT file, because SubRip has no positioning of any kind. The formatting the original program supported was limited to bold, italic, underline and colour, derived from HTML tags, and none of it addresses placement; the Matroska container confirms the same shape from the other side, storing an SRT cue as text plus a timestamp plus a duration and leaving the codec's private data empty, because there are no general settings to record. The {\an8} override you sometimes see in ripped files belongs to a different format and works only in players that happen to honour it. What you can control is the order of the lines inside one cue, which means putting both languages in the same cue and accepting whatever placement the player chooses for the block as a whole. If placement genuinely matters, use WebVTT instead: its cue timings line takes a settings list including alignment, line and position, and it defines REGION blocks for scroll areas — real, specified placement rather than a convention.
When is append mode the right choice, and what is the trap in it?: It is the right choice for one job: a film that arrives as two video files with one subtitle file each. The tool finds the largest end time in the first file, adds the gap you enter in seconds, and adds that total to every timestamp of the second file, so the second part starts cleanly after the first. The trap is that it adds to the second file's existing timestamps instead of replacing them. That is correct when the second file is timed from zero, which it usually is when the two parts were subtitled separately. It is wrong when the second file was cut out of a longer one and still carries its original positions: tested with a second file whose first cue sat at 00:10:00, appending after a 12-second first part with a 1-second gap put it at 00:10:13 rather than 00:00:13, leaving a ten-minute silence in the middle of the result. The fix takes thirty seconds — shift the second file by minus its own first timestamp before merging — but nothing warns you, so check the first cue of the second half in the output.

Articles you may find interesting

All guides →

How-toOut-of-Sync Subtitles: How to Measure the Offset and Shift an SRT by an Exact Number of SecondsMeasure the offset at two points instead of guessing it once. If it is constant, one shift fixes the file. If it grows, it is a frame-rate mismatch — 25 fps against 23.976 drifts 2.5625 seconds every minute — and no shift will ever fix that.How-toSubtitles to a Spreadsheet, and Back: What Survives the Round TripA comma is quoted, a quotation mark is doubled, and a two-line cue keeps both lines — verified byte-identical over three consecutive round trips. What can still change your file is the spreadsheet in the middle.How-toSRT to Text: Getting a Clean Transcript Out of SubtitlesRemoving the numbers and the timestamps is the easy half. The half that decides whether the transcript is readable is the italic tags, the dialogue dashes, the sound descriptions and the sentences broken across two cues — and this converter leaves every one of them for you.ExplainerMP3, WAV, FLAC: What Each Conversion Actually DestroysOne of these formats stores the samples, one stores the same samples packed smaller, and one stores a guess about what you would have heard. Which conversions between them are free, which are merely expensive, and which are one-way doors — with the arithmetic for each.ExplainerPeak Normalisation Versus Loudness Normalisation, and the Target That Cannot Be ReachedScaling until the loudest sample hits a ceiling barely changes how loud something sounds. Measuring in LUFS does. This tool measures — in two passes, correctly — and then prints a result it never verified, which on ordinary material can be well over a decibel adrift.How-toRemoving the Sound From a Video Without Touching the PictureOne ffmpeg command, no encoder, and a result whose video stream is byte-for-byte the one you started with — verified by checksum. Plus why the file barely shrinks, and the difference between a silent track and no track at all.

SubRip has no specification. The Library of Congress records it as only partly documented and not well standardised, so what counts as a valid .srt file is decided by the player, the encoder or the platform that reads it, and two of them will disagree sooner or later. Everything described here was checked against the tool's actual output, not against a standard, because for this format there is none. WebVTT is different — it has a published W3C specification — but it is still a Candidate Recommendation Draft rather than a finished Recommendation. Keep the original file, run the converted one in the player or uploader you actually intend to use before you throw anything away, and treat any claim about what "all players" do, including the ones on this page, as something to verify on yours.

Sources

Spotted a mistake in this article?