or
Drop subtitle files or paste subtitle text, then enter a shift in seconds.
How to measure the offset precisely
- Find an anchor line — pause the video at the exact moment the first clearly identifiable sentence is spoken and note the player time (say
00:01:12). - Find the same line in the subtitles — drop the file above and look up that sentence's start time in the input pane (say
00:01:15). - Subtract: video time − subtitle time — here 72 s − 75 s = −3. Enter
-3in the Shift field; the retimed file appears instantly. - Spot-check near the end — pick a line in the last few minutes and verify it too. If it is still wrong by a different amount, you have drift rather than a constant offset (see below), and shifting alone won't fix it.
Positive or negative? A ten-second rule of thumb
| What you observe | What it means | Shift sign |
|---|---|---|
| Text appears before anyone says it | Subtitles run early — they need to be delayed | Positive, e.g. 2 |
| Text appears after the words were spoken | Subtitles run late — they need to come earlier | Negative, e.g. -2 |
Fractions matter more than you'd think: an error as small as half a second is enough to feel "off" during fast dialogue. The field accepts decimals like -1.25, and the shift is applied with millisecond precision to both the start and end of every cue.
Constant offset vs. drift — know which problem you have
A constant offset (every line wrong by the same amount) is what this page fixes. It typically happens when a subtitle file was timed from a version with a different amount of lead-in — an extra studio logo, a "previously on" recap, or a trimmed cold open.
Drift (the error grows or shrinks over the runtime) cannot be fixed by any single shift. Its classic causes:
- Frame-rate mismatch — timings authored against 25 fps PAL video but played on a 23.976 fps release run fast by about 4%, which compounds to roughly 2.5 seconds of error per minute of runtime.
- Different cut — scenes added or removed mid-video produce a step: perfectly synced up to a point, then suddenly off by a fixed amount. Splitting the file at the step and shifting only the second half works; see the FAQ.
Quick diagnosis: if the offset you measured at the start of the video also fixes the end, shift and you're done. If not, look for a subtitle file matching your exact release before reaching for retiming tools.
What the shifter does at the edges
- Nothing but timestamps change. Text, line breaks and formatting tags pass through byte-for-byte (unless you enable stripping). SRT output is renumbered from 1.
- The format is preserved. This page detects your input format and automatically selects the matching output, so an SRT comes back as SRT and a VTT as VTT — you can still override the menu to convert while you shift.
- No negative timestamps. With a large negative shift, cues that would end at or before
00:00:00.000are dropped (the status line counts them), and a cue straddling zero has its start clamped to zero. If cues vanish, your offset is bigger than the real error.
Subtitle syncing — frequently asked questions
How do I work out the exact number of seconds to shift?
Pause the video the instant the first clearly identifiable line is spoken and note the player time. Find that same line in the subtitle file and note its start time. Subtract: video time minus subtitle time is your shift. If the line is spoken at 1:12 but the cue says 1:15, enter -3. Decimals work too — -2.75 shifts everything 2.75 seconds earlier.
My subtitles start in sync but drift further out over time — will a shift fix that?
No. A growing error means the subtitle file was timed for a different version of the video — most often a frame-rate mismatch (a 25 fps PAL timing played against 23.976 fps film drifts by roughly 2.5 seconds per minute) or a different cut with scenes added or removed. A constant offset cannot correct a changing error; you need a subtitle file made for your exact release, or a retiming tool that can stretch timestamps by a scale factor.
Does shifting change anything in the file besides the timestamps?
The cue text, line breaks and any formatting tags are left untouched unless you also enable tag stripping. SRT cues are renumbered sequentially, and this page automatically keeps the output in the same format it detected — an SRT stays an SRT, a VTT stays a VTT — so only the timing changes.
What happens if my negative shift is bigger than the first cue's start time?
Timestamps can't go below zero. Any cue that would end at or before 00:00:00.000 is removed from the output (the status line reports how many were dropped). A cue that straddles zero keeps its end time but has its start clamped to 00:00:00.000. If early cues are disappearing, your offset is probably larger than the real error.
Can I shift only part of the file, say everything after an ad break?
Not directly — this tool applies one offset to every cue, which is the right fix for a constant delay. For a step change partway through (an inserted ad break or a recap cut from your copy), split the file at the break point in a text editor, shift only the second half here, and paste the halves back together, or use a desktop editor with two-point synchronization.