Subtitle sync and shifter
Fix subtitles that start late — or that drift further out as the film goes on.
Two different problems that look the same
If your subtitles are wrong by a constant amount — two seconds late at the start and two seconds late at the end — you need a shift. Enter the offset and everything moves together.
If they start about right and get progressively worse, a shift cannot help you, and this is where most subtitle tools stop. The file is running at the wrong rate: correct at the beginning, a few seconds out by the middle, wildly wrong by the credits. Adding an offset just moves the whole problem along.
Two-point resync
The fix is to stretch as well as shift, and it takes two reference points. Find a line near the start, note when it currently appears and when it should; do the same for a line near the end. From those four numbers the correct scale and offset both follow, and every cue in between lands where it belongs.
Pick the second point as late in the film as you can. Two points close together give an accurate offset and a badly estimated stretch, which is worse than not stretching at all.
It is almost always the frame rate
Progressive drift nearly always means the subtitles were timed against a different frame rate from the video you have. The common pair is 25 fps — European broadcast — against 23.976, which is film transferred for NTSC. The ratio is 1.042709, so a file that is right at the first line is 307 seconds out by the end of a two-hour film. That is a little over five minutes.
The figure usually quoted for this is four minutes. It is worth doing the arithmetic rather than repeating it: 7200 seconds times 0.042709 is 307.5. If you know both frame rates, the frame-rate mode applies exactly that ratio and you need no reference points at all.
Cues pushed before the start
Shift a file earlier and some cues can end up before zero. Clamping them all to 00:00 stacks a pile of zero-length cues at the start, which players show as a flicker of every early line at once. So a cue that ends at or before zero is dropped, one that merely starts early is clamped, and you are told how many of each.
Milliseconds, as integers
Every time here is handled as a whole number of milliseconds rather than as seconds with a decimal point. Floating-point seconds accumulate error across a few thousand cues, and it surfaces as timings a millisecond out — which looks like a bug in the tool and is really just arithmetic. Integers do not drift.
Finding the right offset
Play the video and note when a line is actually spoken, then look at when the subtitle says it should appear. The difference is your offset. If the subtitle appears after the speech, it is late and needs a negative shift; if it appears before, positive. Getting the sign backwards is the most common mistake, and doubling the error makes it obvious quickly.
It runs in your browser
No upload, no limit, and it will read SRT, WebVTT or ASS and write back out in whichever format you need.
Common questions
My subtitles start right but drift later. What do I do?
Use the two-point resync. A constant shift cannot fix drift. Give it a line near the start and one near the end, with their current and correct times.
Which sign do I use?
Negative makes subtitles appear earlier, positive later. If the subtitle shows up after the line is spoken, it is late, so use a negative number.
What causes progressive drift?
Nearly always a frame-rate mismatch — usually 25 fps against 23.976. That ratio puts a file 307 seconds out by the end of a two-hour film.
Where do I find the frame rates?
The video information tool will tell you the video\u2019s. The subtitle\u2019s is usually stated where you downloaded it, or you can infer it from the drift.
What happens to subtitles pushed before the start?
A cue that ends before zero is dropped; one that merely starts early begins at 00:00. Both counts are reported so nothing disappears silently.
Can it change format at the same time?
Yes — pick the output format and it converts while it resyncs.