How to fix subtitle timing

Spend thirty seconds diagnosing first. Note how far off a line near the START is, then a line near the END. If both are wrong by about the same amount, you need a SHIFT. If the error grows as the video plays, you need a SCALE.

Applying the wrong one makes things worse, and it is the reason people end up shifting the same file four times. Shift moves every cue by a fixed number of milliseconds; scale multiplies every timestamp by a factor, which is the correct fix for drift.

Last reviewed: 2026-09-19. Checked against the tool’s own source on that date.

Constant offset, or drift?

A CONSTANT OFFSET means the subtitles are wrong by the same amount everywhere. A line at 00:01:00 is two seconds late and a line at 01:40:00 is also two seconds late. The usual cause is a release with a different intro length, or a file timed against a version with adverts cut.

DRIFT means the error grows as the video plays. The first line is nearly right and the last line is forty seconds out. This almost always comes from a frame-rate mismatch: the subtitles were timed against a 23.976 fps release and your video runs at 25 fps, or the other way round.

The test is the same either way: check one line near the beginning and one near the end. Two similar errors mean shift. A growing error means scale.

  1. Note how far off a line near the START is.
  2. Note how far off a line near the END is.
  3. Similar errors: use Shift.
  4. Growing error: use Scale.

Shifting

Enter the offset in milliseconds. A positive number delays the subtitles, which is what you want when they appear too early. A negative number moves them earlier, for subtitles lagging behind the dialogue.

Measure rather than guess. Note the timestamp where a line is actually spoken and the timestamp where it currently appears; the difference is your offset. Two seconds is 2000 ms.

Timestamps are clamped at zero, because neither SRT nor WebVTT can represent a negative time and a player handed one behaves unpredictably. Shifting backwards by more than the first cue’s start time pins the affected cues to 00:00:00, and the tool tells you how many. That warning is a signal your offset is probably too large, and it is also why a large negative shift is not reversible by shifting forward again.

Scaling for a frame-rate change

Scaling multiplies every timestamp by a constant factor. The factor is the ratio of the frame rates.

Subtitles timed for 23.976 fps against a 25 fps video: multiply by 25 divided by 23.976, approximately 1.0427. Going the other way: 23.976 divided by 25, approximately 0.959.

If you do not know the frame rates, derive the factor from the drift itself. Divide the correct time of the last line by its current time. Apply it, then re-check both ends — a scale usually leaves a small residual offset that one shift finishes off.

Merging and splitting

Films released as two files need merging. Load the main file, choose the second in the merge panel, and give it an offset: where the second part begins in the combined timeline. If part one runs 58 minutes 20 seconds, the offset is 3,500,000 ms. Cues from both are combined, re-sorted by start time and renumbered from 1.

Splitting does the reverse at a timestamp you choose. By default the second part is rebased to start from zero, which is what you want when it will be played against a separate video file. A cue straddling the split point goes with the part it began in rather than being cut in half.

Worked example: a file that drifts by 40 seconds over 90 minutes

The first line should appear at 00:00:32 and appears at 00:00:31 — near enough. The last line should appear at 01:28:10 and appears at 01:24:33. The error grows, so this is drift, not an offset.

Convert both to seconds. The correct time is 5,290 seconds; the current time is 5,073 seconds. The factor is 5290 divided by 5073, which is 1.0428.

That is almost exactly 25 divided by 23.976, which confirms the diagnosis: subtitles timed for a 23.976 fps release, played against a 25 fps video.

  1. Apply a scale factor of 1.0428.
  2. Re-check the first line and the last line.
  3. The last line now lands correctly; the first has moved from 31 to about 32.3 seconds, roughly a third of a second late.
  4. Apply a shift of -300 ms to finish.

Result: Both ends are within a few tenths of a second, which is inside the range a viewer reads as synchronised. Two operations, in the right order: scale for the drift, then a small shift for the residual.

Open the tool

Shift or scale timings in the Subtitle Toolkit

Applies whole-file shifts and scales in your browser, and warns you when a shift has clamped cues at zero.

What this does not cover

  • Shifting and scaling apply to the whole file. There is no way to retime only a selected range of cues.
  • Timestamps are clamped at zero, so a large negative shift loses information and cannot be undone by shifting forward.
  • SRT and WebVTT only.
  • The tool cannot detect the frame rate of your video, or of the file the subtitles were timed against. Both diagnoses come from you.
  • There is no audio analysis and no automatic sync detection.