SRT Subtitle Resync Tool

Why subtitles drift

SRT (SubRip Subtitle) is the most common subtitle format on the web — plain text, one cue per block, with HH:MM:SS,mmm start and end timestamps. The format dates from 2002 and is supported by virtually every video player. The trouble starts when subtitles you downloaded don't match the video you have. There are three reasons subtitles drift, each with a different fix.

First reason: constant offset. The subtitles start too early or too late by a fixed amount. Common cause: the video file has a different intro length (different opening credits, different ad-insertion start) than the file the subtitles were timed against. Fix: shift all timestamps by the same delta. Second reason: linear stretch. Subtitles align at the start but drift further apart over time. Almost always caused by framerate conversion (23.976 fps to 25 fps is the classic culprit). Fix: multiply all timestamps by a constant factor. Third reason: piecewise drift. Subtitles align in some sections and drift in others, usually because the video has scenes inserted or removed. Fix: split into segments and shift each separately.

Diagnosing what kind of drift you have

Open the subtitle file in any text editor. Note the timestamp of the FIRST cue and the timestamp of the LAST cue. Play your video and pause at the moment the first cue should appear — note that time. Pause at the moment the last cue should appear. If both are off by the same amount, you have a constant offset: shift. If the first cue is off by X and the last cue is off by 2X or more, you have linear stretch: use the stretch factor.

Quick math for the framerate-conversion case. If your subtitles were timed for 23.976 fps (NTSC film) but your video is 25 fps (PAL TV), the stretch factor is 23.976/25 = 0.95904. If you have it the other way (25 fps subtitles for 23.976 fps video), the factor is 1.04271. Other common conversions: 24 fps to 23.976 fps = 1.001, and 29.97 fps to 25 fps = 1.1988.

Shift mode: the simple case

Shift adds (or subtracts) a constant duration to every timestamp. Positive values delay the subtitles, negative values bring them earlier. A shift of +1.5 means every cue appears 1.5 seconds later than originally timed. The math is straightforward: new_time = old_time + offset_ms.

Edge cases: cues that would shift to a negative time get clamped to zero (you can't have a cue start before the video starts). Cues shifted past the video's end are still written but won't display — they're harmless. If you find yourself shifting by more than 5 seconds, the subtitles probably belong to a different version of the video (extended cut, different region), and shifting won't fix everything.

Stretch mode: the linear case

Stretch multiplies every timestamp by a constant factor. A factor of 1.04271 makes a 1-hour video's timestamps 4.271% later — useful for 23.976→25 fps conversion. The math: new_time = old_time × factor. Note that this affects BOTH the start and end timestamps of each cue, which is what you want — the cues themselves don't change duration relative to the dialogue.

Combining shift and stretch: if subtitles need BOTH (the start is off by 2 seconds AND they drift), you can run stretch first, then shift to align the start. The other order — shift first, then stretch — works arithmetically but is harder to reason about because the shift offset itself gets multiplied.

Encoding and line-ending gotchas

SRT files come in inconsistent encodings. UTF-8 with BOM is most common today, but older files might be Windows-1252 or ISO-8859-1, which break on accented characters and emoji. Best practice: convert to UTF-8 without BOM before editing. Our tool preserves whatever encoding you paste in — it works on the timestamp pattern and doesn't touch the dialogue text.

Line ending also matters: Windows files use CRLF, Unix files use LF. Some video players only accept one or the other. If your subtitles look fine in a text editor but the player shows no text, try resaving with the opposite line ending.

Beyond SRT: when to consider other formats

SRT is great for simple subtitles but lacks features for advanced cases. WebVTT (.vtt) is the web standard, supports CSS styling, positioning, and language metadata. ASS/SSA (.ass) supports karaoke, fancy fonts, rotated text — used for anime fansubs. EBU-TT and TTML are XML-based formats used in broadcast.

If your goal is just to play the video on your laptop and the subtitle source is SRT, stick with SRT — most players handle it best. If you're publishing video on the web, WebVTT is the right target — most browsers play VTT natively but require player libraries for SRT. ffmpeg can convert between any of these formats: `ffmpeg -i input.srt output.vtt` is enough for most use cases.

Privacy note

The tool processes SRT text on the server (Node.js) and immediately returns the result without storing it. No file is uploaded as a file — the text is sent as a JSON POST, processed in memory, and the response is the modified text. Server logs don't include payload content. If you have particularly sensitive subtitles (corporate training, unreleased film), running a local equivalent is straightforward: the resync logic is pure arithmetic that fits in 30 lines of Python or JavaScript.