Stretch Subtitles to Match Video
Or paste subtitle text
Options
How long the video is, written as milliseconds, seconds or a timecode (1500, 24m, 00:24:00,000 all work). The ratio is worked out from the file itself: the last moment any cue is on screen is measured, and that is what gets stretched or squeezed to this length. Useful when you know the runtime of the version you are matching, not the ratio.
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.
Fill in Target length to run.
Type in how long the video is and this page works out the ratio for you. The length of the subtitle file is measured from the file itself — the largest end time anywhere in it — and every timestamp is multiplied by target divided by that. No percentage to calculate, and the last subtitle lands on the end of the video rather than wherever it happened to stop.
The measurement uses the largest end time in the file, not the end of the last cue in the list. In real files those are often different: a narration line can open early and stay on screen across several short replies, so the cue that ends latest is not the one written last. Measuring with the wrong one gives you a ratio that is off by however much the two differ, which is the kind of error that only shows up in the last few minutes of an episode.
The target box takes a length in whichever form you have it: milliseconds, seconds and minutes with an `s` or `m` suffix, or a full timecode. That last option is a length and not a moment on the timeline, which is why a duration is what you type here and not a start time.
A shorter target compresses the file instead of stretching it; there is nothing to switch over, and a file that is too long for its video is the same problem in the other direction. Everything is measured from zero, so a lead-in before the first line of dialogue scales along with the rest — if the opening titles must stay put and only the end needs to move, a constant offset or a two-point sync is the right tool rather than a ratio.
SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON and CSV are read as what they are rather than as their extension suggests. Plain text and LRC are refused, because neither stores an end time for the file to be measured with. The whole thing runs in the browser tab, so a season of episodes can go through the queue without a single byte leaving the machine.
Examples
An eight-second file against a ten-second video
Input
1
00:00:01,000 --> 00:00:03,000
Hello there.
2
00:00:05,000 --> 00:00:08,000
Second line.
Output
1
00:00:01,250 --> 00:00:03,750
Hello there.
2
00:00:06,250 --> 00:00:10,000
Second line.
Target length set to 00:00:10,000, so the ratio is 10 divided by the file's 8 seconds — one and a quarter, with nothing worked out by hand. The last cue now lands on ten seconds exactly, because that is the moment the ratio was measured against, while the first cue moves a quarter of its own distance from zero.
A file that is too long for its video
Input
1
00:00:00,000 --> 00:00:10,000
A long opening line.
2
00:00:02,000 --> 00:00:03,000
Short.
3
00:00:04,000 --> 00:00:05,000
Also short.
Output
1
00:00:00,000 --> 00:00:06,000
A long opening line.
2
00:00:01,200 --> 00:00:01,800
Short.
3
00:00:02,400 --> 00:00:03,000
Also short.
Target set to 6s against a ten-second file, so this is the compressing direction and the ratio is 0.6. The file is ten seconds long because the first cue ends there, not because of the last cue written, whose end is only five seconds past zero — measuring with that one would have produced a ratio of 1 and handed the file straight back. Compressing squeezes every cue, so the reading speed goes up and nothing about the words changed.
The lead-in moves too
Input
1
00:01:00,000 --> 00:01:02,000
Lead-in ends, speech starts.
2
00:02:00,000 --> 00:02:02,000
One minute in.
Output
1
00:01:30,000 --> 00:01:33,000
Lead-in ends, speech starts.
2
00:03:00,000 --> 00:03:03,000
One minute in.
Target 3m3s against a file whose longest end is 2m2s, so the ratio is 1.5. The box takes minutes, and it also takes 183000 or 00:03:03,000 — all three mean the same thing. Note that the first cue opened at one minute and now opens at one and a half minutes: everything is measured from the start of the timeline, so the silent lead-in is stretched along with the dialogue.
Frequently asked questions
How do I find out how long my subtitle file is?
The page measures it for you: it takes the largest end time anywhere in the file and treats that as the file's length. You only have to supply the length of the video. If you want to know the number before running anything, the last cue in a well-formed file is usually close to it, but a long cue spanning several short ones makes the two differ.
What if the target length I type is shorter than the file already is?
The file is compressed, not stretched, and nothing needs to be switched over to a different mode. A 10-minute file with a 6-minute target is multiplied by 0.6, so every cue keeps 60 percent of its screen time. That raises the reading speed of every line, and it is worth checking the reading speed page before shipping a compressed file to a broadcaster.
Why did the first subtitle move when I only wanted the end to line up?
Because the ratio is applied to the distance from zero. A file whose first line opens at one minute against a 1.5 times stretch now opens at one and a half minutes, so the silent lead-in is stretched along with the dialogue. If the opening titles are fixed and only the tail is wrong, that is not a ratio problem: use a constant offset, or a two-point sync that holds a chosen moment in place.
Can I type the target length in minutes instead of a timecode?
Yes. The box accepts a plain millisecond count, a duration like 90s or 24m or 1h2m, and a full timecode such as 00:24:00,000 — all four mean the same thing and none is more correct than another. Use whichever form matches what your video tool shows you, since retyping a number into a different shape is where transcription errors come from.
The subtitles still do not line up after stretching. What else could be wrong?
If one end of the file lines up but the middle does not, the file was cut or the video was re-edited, and a two-point sync using both of those moments is what fixes it. If every subtitle is late by the same amount, that is a constant offset and belongs on the shift page. If the drift only appears after a frame rate conversion, the frame rate pages work from the rates themselves instead of a measured ratio.
What happens if I leave the target length empty?
The run does not start, and the page says a required field is missing. That is deliberate: any default value would be a real length, so a file dropped in and run without reading the box would come back silently stretched to something nobody chose, with nothing in the output to say so. Alongside the button the page also tells you the length it measured from the file, so you can compare before committing.