SRT shifter: adjust subtitle timing

Move every subtitle earlier or later by any amount to fix a constant sync offset, in your browser, in seconds. Only the timestamps change; numbering, text, and formatting stay untouched.

Choose .srt fileor paste the SRT below

Direction

Later (subtitles appear too early)Earlier (subtitles appear too late)

Shift by (seconds)

Decimals are milliseconds — 0.5 is half a second.

First subtitle

—

Delay or drift? The 10-second diagnosis

Subtitle sync problems come in exactly two shapes. A constant delay, every line off by the same amount, usually because the video has a different start point than the subtitles were made for, is what this tool fixes. Progressive drift, sync that gets worse as the video plays, means the subtitles were timed at a different frame rate, and no fixed shift can fix it; that file needs retiming by rate instead.

Quick test: check the sync in the first minute and again near the end. Same offset both places? Shift it here. Bigger offset at the end? It is a frame-rate mismatch.

Worked examples

The shift outputs below were produced by this tool.

Shift 2.5 seconds later: 00:00:01,000 --> 00:00:03,400 becomes 00:00:03,500 --> 00:00:05,900, and a cue at 00:01:00,500 becomes 00:01:03,000. Every cue moves by exactly 2,500 ms; durations are unchanged.
Shift 1.2 seconds earlier: a cue at 00:01:00,500 becomes 00:00:59,300. Enter 1.2 with the direction set to earlier.
Clamping at zero: with the same 1.2 second earlier shift, a first cue at 00:00:01,000 would land at minus 200 ms, so it is clamped to 00:00:00,000 and the tool reports one clamped timestamp. The rest of the file shifts normally.
A frame-rate mismatch, which shifting cannot fix: subtitles timed for 25 fps played against 23.976 fps video. The ratio is 25 / (24000 / 1001) = 1.0427, so a cue meant for 10:00 appears at 10:25.6 and a cue meant for 60:00 appears at 62:33.8. The offset grows with time, which is the signature of drift. Those timestamps need multiplying by 1.0427, not adding to. The frame rate converter shows the same relationship for timecode.

How it is calculated

Each timestamp is parsed to milliseconds, ms = ((h x 60 + m) x 60 + s) x 1000 + mmm, the offset is added or subtracted, negative results are clamped to zero, and the value is written back as HH:MM:SS,mmm. That is the whole operation, which is why a constant delay is always safe to fix this way.

Drift is a different operation: newMs = ms x (sourceFps / targetFps). For 29.97 fps material the exact rate is 30000 / 1001, so subtitles timed at a flat 30 fps drift 3.6 seconds an hour, the same 1.001 factor behind drop-frame timecode. The drop-frame timecode guide explains that factor, and the timecode calculator converts a frame offset into seconds when your sync note is in frames. If the retimed subtitles are headed for an Avid timeline, the SRT to Avid TXT converter writes them at the frame rate the sequence needs.

FAQ

How do I adjust SRT timing?

Load the .srt here, choose later or earlier, enter the offset in seconds, and download. Every timestamp moves by the same amount. If subtitles appear 2.5 seconds before the words are spoken, shift them 2.5 seconds later; if they lag behind, shift earlier.

How do I fix subtitles that are out of sync?

If every subtitle is off by the same amount, shift the whole file: load the SRT, choose later (subtitles show too early) or earlier (they show too late), enter the offset in seconds, and download. If the drift grows over the runtime, the problem is a frame-rate mismatch, not a delay. See the frame rate converter instead.

How do I know how much to shift by?

Find one line you can pin to the audio: note when the subtitle appears and when the word is actually spoken. The difference is your offset. The first-subtitle preview updates live so you can sanity-check before downloading.

Why do my subtitles drift later over time?

Progressive drift means the subtitles were timed at a different frame rate than the video. Subtitles made for 25 fps played against 23.976 fps material run 4.27% slow: 25.6 seconds late after ten minutes and 2 minutes 34 seconds late after an hour. A fixed shift cannot fix that; the timestamps have to be scaled by the rate ratio.

Does shifting change anything else in my file?

No. Only the timestamps are rewritten. Numbering, text, line breaks, and formatting stay byte-for-byte identical, so the file works exactly as before, just retimed.

What happens if shifting earlier would make a timestamp negative?

Timestamps that would go below zero are clamped to 00:00:00,000 and the tool tells you how many were affected. A cue at 00:00:01,000 shifted 1.2 seconds earlier lands at 00:00:00,000 and is reported as one clamped timestamp. If your first real subtitle starts after the offset, nothing clamps.

Can I shift by milliseconds or by frames?

Enter decimals for milliseconds: 1.2 means 1,200 ms. For a frame-based offset, divide by the frame rate first: 3 frames at 25 fps is 0.12 seconds, and 3 frames at 23.976 fps is 0.125 seconds. The timecode calculator does that arithmetic if you would rather not.

Can I shift only part of the file?

Not with this tool; it moves every cue by the same offset, which is what a constant delay needs. If only the second half is out of sync, the file usually has two different problems joined together, and the halves are best fixed separately.

Is my file uploaded anywhere?

No. This tool runs entirely in your browser. For format conversions (SRT to VTT, Premiere, Word) the converters on this site process files server-side; the shifter never sends your file anywhere.