Set a Minimum Subtitle Duration
Or paste subtitle text
Options
A duration — 1000, 1s, 1.5s and 00:00:01,000 all work. This is the line between a subtitle that lingers long enough to be read and one that flashes past. What happens on the wrong side of it depends on the page you are on: closing gaps holds the short cue on screen for longer, taking the added time out of the gap that follows so no cue ever covers the next one's words (the last cue in the file has nothing after it and simply extends), while a check page lists every cue under the line and leaves the file untouched.
The blank between two cues has two edges: the earlier cue's end and the later cue's start. End moves the earlier cue's end, so closing a gap lengthens that cue and widening one shortens it; the later cue keeps its timing to the millisecond. Start moves the later cue's start instead and leaves the earlier cue alone. Pick the one whose timing you trust more — usually the cue whose text is spoken last, since a cue should not appear before its line is heard.
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.
This page makes sure nothing flashes past. Give it a minimum duration — one second, where the box starts — and any cue shorter than that is held until it has been on screen for the full length. The extra time is taken from the blank screen that follows the cue, so nothing downstream is pushed later and no cue ever ends up covering the next one's words. A file whose cues are already long enough comes back byte for byte.
The value is a duration, not a count of milliseconds, so it accepts whichever way you write it: 1000, 1s, 1.5s or 00:00:01,000 all mean the same thing and any of them will do. The number itself is usually a house rule rather than something you work out from the file — a broadcaster's style guide, a client's delivery spec, or simply the shortest a line can be and still be read by someone who is not already looking at the screen.
Which edge moves decides what the viewer experiences. End, the default, keeps the cue up after the line has been spoken, so the words arrive when the file said and linger. Start brings the cue in earlier instead, so the line is on screen before it is heard — the reading speed drops either way, but the second option is the one for narration that is already a beat late. Either way the cue only ever grows, and it grows in the direction you chose.
Two things this page will not do. It will not hold a cue past the moment the next one begins: where the following cue starts too soon there is simply no room, and the cue stops at that boundary and is reported as not having reached your number. And it will not touch anything else — text, styles, positions, karaoke timings and cue count all survive untouched, so it is safe on an ASS file with heavy styling. Nothing is uploaded; the file is read and written in the tab, and SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON and CSV are all accepted.
Examples
Two cues shorter than a second
Input
1
00:00:01,000 --> 00:00:01,300
Quick.
2
00:00:03,000 --> 00:00:03,200
Blink.
3
00:00:05,000 --> 00:00:07,000
A comfortable one.
Output
1
00:00:01,000 --> 00:00:02,000
Quick.
2
00:00:03,000 --> 00:00:04,000
Blink.
3
00:00:05,000 --> 00:00:07,000
A comfortable one.
The 300 ms cue and the 200 ms cue are each held until they have been up for a full second, while the third cue — already two seconds long — does not move at all. Look at where the added time comes from: each cue takes it from the blank screen after it, so the second cue still starts at 3000 and no boundary downstream shifted. On the timeline preview the two short bars grow to the right.
The next cue is closer than the limit needs
Input
1
00:00:01,000 --> 00:00:01,200
Short.
2
00:00:01,500 --> 00:00:03,000
Next.
Output
1
00:00:01,000 --> 00:00:01,500
Short.
2
00:00:01,500 --> 00:00:03,000
Next.
To be a full second long the first cue would need to run to 2000, but the second cue starts speaking at 1500. So the first cue stops exactly where the next one begins and is 500 ms long instead of the 1000 asked for. Covering the next cue's words would be a worse fault than a short cue, so the surrounding cues win whenever the two requirements collide.
With the earlier edge moving instead
Input
1
00:00:01,000 --> 00:00:02,000
First.
2
00:00:05,000 --> 00:00:05,300
Quick.
3
00:00:09,000 --> 00:00:10,000
Last.
Output
1
00:00:01,000 --> 00:00:02,000
First.
2
00:00:04,300 --> 00:00:05,300
Quick.
3
00:00:09,000 --> 00:00:10,000
Last.
The short cue is not held longer here — it appears earlier, at 4300 rather than 5000, and its ending stays exactly where the file put it. The first cue keeps every millisecond, because an earlier start stops at the previous cue's end. Both runs make the same cue one second long; which is right depends on whether the line should be read after it is spoken or before.
Frequently asked questions
How long should a subtitle stay on screen at minimum?
There is no single number that fits every project, which is why this page asks you for one instead of choosing. A common starting point is one second per short line, which is what the box is set to, and many delivery specifications quote a figure in that region for material that has to be readable by someone who was not already watching. If your file has a style guide behind it, use that figure; if not, one second is a reasonable first pass, and you can always run it again with a different number.
Does a cue ever get held past the start of the next one?
Never. The cue stops at the next cue's start time even when that means the result is shorter than the minimum you entered, because a cue that runs into the following one puts two lines on screen at once and reads worse than a brief cue. A file that has been cut tightly will therefore show a few cues that did not reach your number; the run reports how many rather than forcing them through.
Which end of the cue grows when I lengthen it?
The one you pick. End holds the cue after the line has finished, so the words appear when the file said and stay up longer — the safest default, and the one this page starts on. Start moves the whole cue back in time so it appears before it is spoken, which keeps the original ending but makes the line show slightly early. Either direction changes the reading speed in the same way; they differ only in whether the viewer sees the words before or after hearing them.
Can I lengthen every cue in the file to the same duration?
Only the ones below your number, and only up to it. Cues that are already at or above the minimum are left exactly as they are, at whatever length the file gave them — a long cue is not shortened to match. That is the difference between a floor and a fixed duration: this page raises short cues to a level and leaves everything else alone, so a file with one or two flickers in it does not end up with a uniform rhythm it never had.
What if my duration is written in seconds rather than milliseconds?
Write it in seconds. The box accepts a bare number as milliseconds and a number with an s suffix as seconds, so 1500 and 1.5s are the same request, and a full timecode such as 00:00:01,500 works too. Whichever you type, the value ends up as a whole number of milliseconds internally, because that is the only time unit used anywhere on this site — which also means a cue length that works out to a fraction of a millisecond is rounded rather than stored.
Does the styling on my cues survive the change?
Entirely. The page changes two numbers per cue and nothing else: the text, the per-word tags, the style reference, the position, the layer and the number of cues are all carried through as they were. That holds for ASS and SSA in particular, where a cue can carry a style name, a positioning override and karaoke timing at once — all of it is preserved, and a file with nothing short in it is returned byte for byte.