Subtitles Out of Sync? Fix Drift and Delay (Frame Rate & Timing Guide)

You downloaded a subtitle file, or exported one from another tool, and it doesn't line up with the speech. Maybe every line lands a couple of seconds late. Maybe the first scene is perfect but by the end the subtitles are a sentence ahead. These look like the same bug, but they have two different causes and two different fixes, and the wrong fix makes things worse.

Diagnosis: offset or drift

Pick a clearly audible line near the start of the video and note how far off the subtitle is. Then do the same with a line near the end.

What you observe	Cause	Fix
Off by the same amount at the start and the end	Constant offset: everything is uniformly early or late	Shift the timing
In sync at the start, worse by the end	Progressive drift: a frame-rate mismatch	Convert the frame rate
Off in different directions in different scenes, no clear pattern	Irregular desync: edits, removed ad breaks, or a botched frame-rate conversion	Re-time by section, or transcribe again

If you have both drift and an offset, fix the drift first with the frame-rate converter, then measure what's left and shift it.

Path 1: Constant offset

The subtitles are correctly paced (the gaps between lines match the speech), but the whole track starts at the wrong moment. Common causes:

The file was made for a release with a different intro: a studio logo or recap you don't have, or the other way round.
The subtitles were timed against a trimmed or padded copy of the video.

How to fix it

Find a distinctive line of dialogue and note the exact time it's spoken in your player.
Note the timestamp on the subtitle for that line.
The difference is your offset. If the subtitle appears at 00:01:05 but the line is spoken at 00:01:02.5, the subtitles are 2.5 seconds late, so the offset is -2.5.
Paste or open the file in the subtitle shifter, enter the offset in seconds (positive moves subtitles later, negative moves them earlier), and download the corrected SRT.

The shifter adds the same offset to every cue and renumbers the output. A cue that a negative shift would push entirely before 00:00:00 is dropped, and one that only starts before zero is clamped to start at 00:00:00,000. It accepts SRT or VTT and runs in your browser without uploading the file.

Path 2: Progressive drift

Drift looks fine when you first press play. The subtitles are in sync for the first minute, slightly off after ten, and a sentence out of step by the end. A growing error is the signature of a frame-rate mismatch.

Why frame rate causes drift

A subtitle timestamp is an absolute time: 00:42:17,500 means 42 minutes and 17.5 seconds in. But the runtime of the same film changes with the frame rate it's played at.

Take a film shot at 24 fps. Two things commonly happen to it:

PAL release (25 fps): the film is simply played one frame per second faster to fit 25 fps television. It runs about 4% shorter, and the audio rises by roughly three-quarters of a semitone. This is the "PAL speedup".
NTSC and Blu-ray release (23.976 fps): the film is slowed by the NTSC factor of 1000/1001, about 0.1%.

A subtitle file timed to the 25 fps PAL copy assumes the shorter runtime. Play it against the 23.976 fps version and every cue fires too early. Because the error is a percentage of elapsed time, it's negligible at the start and several seconds by the end.

The fix is multiplication, not addition

A shift moves every cue by the same amount, but drift needs each cue moved in proportion to its timestamp. The correct operation is to rescale every timestamp:

new_time = old_time × (source_fps ÷ target_fps)

The frame-rate converter does exactly this. Set source fps to the rate the subtitle file was timed against and target fps to the rate of the video you're watching:

A PAL-timed SRT (25) on a film-rate Blu-ray (23.976): source 25, target 23.976. Every timestamp is multiplied by 25 ÷ 23.976 ≈ 1.0427, stretching the track about 4% to match the longer film.
An SRT timed for a 30 fps export on a 29.97 fps video: source 30, target 29.97. A 0.1% correction, which on a two-hour (7,200-second) film removes about 7 seconds of drift by the end.

Both fields suggest the standard rates (23.976, 24, 25, 29.97, 30, 50, 59.94 and 60), and you can type any other value. The converter outputs SRT and runs in your browser.

The frame rates you'll meet

Frame rate	Where it comes from	Notes
23.976	NTSC film (24 × 1000/1001)	Film on Blu-ray and streaming
24	Cinema	The nominal film rate, often a rounded label for 23.976
25	PAL (European and Australian broadcast and DVD)	The source of the 4% "PAL speedup" drift
29.97	NTSC broadcast and DVD (30 × 1000/1001)	The real rate behind a "30 fps" NTSC label
30	Some web video and screen recordings	Differs from 29.97 by 0.1%
50 / 59.94 / 60	High-frame-rate video, sports, gaming	59.94 is to 60 what 29.97 is to 30

The pairs that cause trouble:

23.976 and 25 (film vs PAL): about 4.3% drift. The big, obvious one.
23.976 and 24, 29.97 and 30: the 0.1% NTSC factor, about 7 seconds across a feature film.
59.94 and 60: the same 0.1% NTSC factor at high frame rates.

A note on drop-frame timecode

If you've worked in broadcast or a video editor, you've seen the choice between drop-frame and non-drop timecode. It comes from the same 1000/1001 gap.

NTSC plays at 29.97 fps, but timecode counts a round 30 frames per second. Left alone, that timecode falls about 3.6 seconds behind real time every hour. Drop-frame timecode skips two frame numbers at the top of each minute (except every tenth minute) so its labels keep pace with the clock. Non-drop counts straight through and slowly falls behind.

Drop-frame changes only how frames are labeled, not how fast they play. SRT stores real milliseconds rather than frame numbers, so you never choose drop-frame when shifting an SRT. But if an export pipeline treated 29.97 fps footage as a flat 30 fps when it wrote the SRT, you'll see the 0.1% drift, and a 30 to 29.97 conversion corrects it.

When neither tool is enough

A single shift or rescale fixes uniform problems. It can't fix irregular desync:

The video was re-cut (ad breaks removed, scenes trimmed), so the offset changes at each cut.
The video was converted to or from variable frame rate (VFR, common in screen recordings and phone video) by a tool that mishandled the timing, so the error varies through the file and no single ratio applies.

Then you have to re-time the file section by section, or make a new subtitle file from the video you actually have.

Transcribing your own copy

Most sync problems start with a subtitle file timed for a different release of the video. Subtitles transcribed from the file in front of you are timed to that file's own audio, so there's no other frame rate or runtime to match. Picute transcribes a video file or a YouTube link in 60 languages and exports SRT, VTT, or an MP4 with the subtitles burned in.