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 feel like the same bug, but they have two different causes and two different fixes — and using the wrong one makes the problem worse.
This guide shows you how to tell them apart in thirty seconds, why frame rate is the hidden culprit behind the second kind, and exactly which free in-browser tool corrects each.
The 30-second diagnosis: offset vs drift
Before touching any setting, run one test. Pick a clearly-audible line near the start of the video and note how far off the subtitle is. Then pick a line near the end and check again.
| 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 (the gap grows) | Progressive drift — a frame-rate mismatch | Convert the frame rate |
| Off in different directions in different scenes, no clear pattern | Irregular desync — edits, ad-break removal, or variable frame rate | Re-time by section, or transcribe fresh |
That single observation — does the error stay constant or grow? — picks your tool. The rest of this guide explains each path.
Path 1 — Constant offset (the whole track is early or late)
This is the simpler case. The subtitles are correctly paced — the gaps between lines match the speech — but the entire track starts at the wrong moment. Common causes:
- The subtitle file was made for a release with a different intro length (a studio logo or recap you don't have, or vice versa).
- Your player added or dropped a fixed delay.
- The subtitles were authored 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 same 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 → shift them −2500 ms.
- Paste the file into the subtitle shifter, enter the offset (positive to push later, negative to pull earlier), and download the corrected SRT.
The shifter adds the same millisecond offset to every cue and renumbers the output. Cues that a large negative shift would push before 00:00:00 are clamped to the start (or dropped if they'd end before zero), so a sensible offset never corrupts the file.
Path 2 — Progressive drift (the gap grows over time)
This is the one that confuses people, because it looks fine when you first hit play. The subtitles are in sync for the first minute, slightly off after ten, and a full sentence out of step by the end. That growing error is the fingerprint of a frame-rate mismatch.
Why frame rate causes drift
A subtitle timestamp is an absolute time — 00:42:17,500 means "42 minutes, 17.5 seconds in." But the runtime of the very same film changes depending on the frame rate it was encoded at, because frame rate sets how fast those frames play.
Take a film mastered at 24 fps. Two things commonly happen to it:
- PAL release (25 fps): the film is played one frame per second faster so it fits 25 fps television. It now runs about 4% shorter, and the audio pitches up by roughly three-quarters of a semitone — the classic "PAL speedup."
- NTSC release (23.976 fps): the film is slowed by the NTSC factor of 1000/1001 (about 0.1%) so it fits NTSC's color-system timing.
A subtitle file authored against the 25 fps PAL copy assumes the shorter runtime. Play it on the 23.976 fps version and every cue fires too early — and because the error is a percentage of elapsed time, it's negligible at the start and seconds-large by the end. That's drift.
The fix is multiplicative, not additive
You can't shift drift away, because a shift moves every cue by the same amount and drift needs each cue moved by an amount proportional 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 actually watching:
- A PAL-timed SRT (25) onto a film-rate Blu-ray (23.976): source 25 → target 23.976. The ratio 25 ÷ 23.976 ≈ 1.0427 multiplies every timestamp, stretching the track ~4% to match the longer-running film.
- An SRT timed for a 30 fps export onto a 29.97 fps NTSC video: source 30 → target 29.97. A 0.1% correction — small, but it removes that ~7-seconds-by-the-end creep.
The tool ships presets for the rates that actually matter: 23.976, 24, 25, 29.97, 30, 50, 59.94, 60. You rarely need to type a custom value — drift almost always comes from one of the standard PAL/NTSC/film pairs.
The frame rates you'll actually meet
| Frame rate | Where it comes from | Notes |
|---|---|---|
| 23.976 | NTSC film (24 × 1000/1001) | Most Blu-rays and streaming films |
| 24 | True cinema / DCP | The nominal film rate; often rounded from 23.976 |
| 25 | PAL (Europe, Australia broadcast & DVD) | The "PAL speedup" source of 4% drift vs film |
| 29.97 | NTSC broadcast & DVD (30 × 1000/1001) | The real rate behind a "30 fps" NTSC label |
| 30 | Some web video, screen recordings | Nominal; mismatches 29.97 by 0.1% |
| 50 / 59.94 / 60 | High-frame-rate, sports, gaming | 59.94 is to 60 what 29.97 is to 30 |
The pairs that cause the headaches:
- 23.976 ↔ 25 — PAL vs film. About 4.3% drift. The big, obvious one.
- 23.976 ↔ 24 and 29.97 ↔ 30 — the 0.1% NTSC factor. Small per minute, ~7 seconds across a feature.
- 50 ↔ 59.94/60 — the same NTSC trick at high frame rates.
A note on drop-frame timecode
If you've worked in broadcast or an NLE you've seen the drop-frame vs non-drop choice, and it's worth understanding because it springs from the same 1000/1001 gap.
NTSC plays at 29.97 fps, but timecode likes to count a round 30 frames per second. Left alone, that timecode clock falls about 3.6 seconds behind real time every hour — a non-drop "one hour" of timecode actually runs about 3.6 seconds longer than a real hour. Drop-frame timecode patches this by skipping two frame numbers at the top of each minute (except every tenth minute) so its labels keep pace with wall-clock time. Non-drop counts straight through and slowly falls behind.
Crucially, drop-frame changes only the labeling of frames, not how fast they play. For SRT this is mostly indirect: SRT stores real milliseconds, not frame-numbered timecode, so you don't pick drop-frame when shifting an SRT. But it's exactly why "30 vs 29.97" confusion produces drifting subtitles — and if an export pipeline stamped your SRT as flat 30 fps over 29.97 footage, the 30 → 29.97 conversion above is the cure.
When neither tool is enough
A single global shift or rescale fixes the two common, uniform problems. It cannot fix irregular desync:
- The video was re-cut — ad breaks removed, scenes trimmed — so the offset changes at each splice point.
- The source is variable frame rate (VFR), common in screen recordings and phone video, where no single ratio applies.
In those cases you have to re-time the file section by section, or — far faster — generate a new subtitle file from the video you actually have.
Avoid the whole problem: transcribe from your own file
Almost every drift-and-delay headache starts the same way: you grabbed a subtitle file that was timed for a different release of the video. The clean way out is to not reuse a mismatched file at all.
When you transcribe the exact video in front of you, the resulting subtitles are timed to that file's own audio — there is no other frame rate, no other runtime, nothing to sync against. Picute does this from a single upload (or a pasted YouTube URL): it generates a clean SRT timed to your file, plus a full plain-text transcript and an optional styled, burned-in video, in 70+ languages. No frame-rate guessing, no offset hunting.
Use the converter and shifter to rescue an existing file; transcribe fresh when you'd rather the problem never existed.
Related reading
- SRT vs VTT vs SBV vs ASS: Subtitle Formats Explained — what each format stores and how to convert between them
- How to Add Subtitles to Long Videos Without Crashes — handling feature-length runtimes where drift is most visible
- How YouTube Subtitles Boost Your Video SEO — why a correctly-timed SRT matters for indexing
Frequently asked questions
My subtitles start in sync but drift further off as the video plays — what's wrong?
That's the signature of a frame-rate mismatch, not a simple timing offset. The subtitle file was timed against a video running at a different frame rate than the copy you're watching. Because the error is a percentage of elapsed time, it's invisible in the first minute and obvious an hour in. The fix is to rescale every timestamp by the ratio of the two frame rates — multiply by source_fps ÷ target_fps. A shift won't help here: shifting moves every cue by the same fixed amount, but drift needs each cue moved by a different amount that grows with time. Use the frame-rate converter, not the shifter.
Is the 0.1% difference between 23.976 and 24 fps (or 29.97 and 30) really enough to matter?
Over a short clip, no. Over a feature-length film, absolutely. The NTSC factor is exactly 1000/1001, about 0.1%. On a two-hour (7,200-second) film that's roughly 7 seconds of drift by the end — far more than enough to break sync on dialogue. This is why a subtitle file labeled '30 fps' often won't hold sync on a 29.97 fps video even though the numbers look almost identical: the real NTSC rates are 24×1000/1001 and 30×1000/1001 — non-terminating values that get rounded to the familiar 23.976 and 29.97, while '24' and '30' are the nominal labels.
What is the PAL speedup, and why does it break subtitles from European DVDs?
To put 24 fps film onto 25 fps PAL television, the entire film is simply played 1 frame per second faster — the '4% speedup' (25 ÷ 24 ≈ 1.0417). The runtime shrinks by about 4% and the audio pitch rises by roughly three-quarters of a semitone (the reason PAL DVDs sound slightly higher than their cinema or NTSC counterparts). A subtitle file timed to the 25 fps PAL release runs about 4% too fast on a 23.976 fps Blu-ray, and vice versa. To move a PAL-timed SRT onto a film-rate copy, convert from 25 to 23.976: each timestamp is multiplied by 25 ÷ 23.976 ≈ 1.0427, stretching the track to match the longer-running film.
What is drop-frame timecode, and do I need to set it for SRT subtitles?
Drop-frame is a timecode-labeling convention, not a change in playback speed. NTSC video runs at 29.97 fps, but its timecode counts a round 30 frames per second; left uncorrected, the timecode clock falls about 3.6 seconds behind real wall-clock time every hour. Drop-frame timecode skips two frame numbers at the start of each minute (except every tenth minute) to keep the labels aligned with real time; non-drop counts straight through and slowly falls behind. For SRT you mostly don't set it directly — SRT stores real milliseconds (HH:MM:SS,mmm), not frame-numbered timecode — but drop-frame exists because of the same 1000/1001 gap that causes subtitle drift. If a tool exported your SRT by treating 29.97 fps footage as a flat 30 fps, you'll see that 0.1% drift, and the frame-rate converter (30 → 29.97) corrects it.
How do I know whether to shift the subtitles or convert their frame rate?
Run the two-point test. Find a clear line of dialogue near the very start and note how far the subtitle is from the audio; then do the same near the very end. If the error is the same at both ends (e.g. about 2 seconds late throughout), it's a constant offset — use the shifter. If it's tiny at the start and large at the end (or vice versa), it's drift — use the frame-rate converter. In the rare case you have both, fix the drift first with the converter, then nudge the leftover constant offset with the shifter.