When do subtitles fall out of sync?
Three common scenarios:
- Different video cut. You downloaded subtitles built for one release of a film, but you have a different release — director’s cut, extended edition, a Blu-ray vs theatrical. Intros, ads, or extra scenes create a constant offset.
- Re-encoded video. The video has a longer or shorter intro than the subtitle author had — common when subtitles come from a TV broadcast (with ad breaks) but you have the streaming version (without).
- Player or codec quirk. Some players add or strip a frame or two at the start of playback. Usually sub-second drift — fixable with a 0.1-0.5s shift.
All three of these are constant-offset problems — the subtitle file is correctly timed within itself, just starting at the wrong moment. That’s what this tool fixes.
When this tool isn’t the right fix
If your subtitles start correctly but drift over time — the first line is in sync, but by the end of a one-hour video they’re 30 seconds off — that’s a frame-rate mismatch, not a constant offset. Common case: the subtitle file was authored for 23.976fps source but your video is 25fps (or vice versa), so the playback speed difference accumulates.
Fixing drift needs a different operation: stretching or compressing the entire timeline by a multiplier. A frame-rate conversion tool handles that. This tool doesn’t — it only does flat offsets.
How to use the synchronizer
- Decide on the shift amount. Watch your video with subtitles on, note when the first spoken line should appear vs when it actually does. The difference (signed) is your shift.
- Enter the shift in the input above. Positive = subtitles appear later. Negative = subtitles appear earlier. Use the buttons for ±0.1s and ±1s nudges, or type a precise value like
−1.75. - Drop your
.srtfile. The tool runs the shift immediately and offers the result as a download. - Test the output in your video player. If the shift was off by a bit, change the number — the tool re-runs against the same file instantly without re-uploading.
A note on the boundary case
If your shift is large enough that some cues would end up with negative timestamps (before 00:00:00), those cues get clamped at 00:00:00,000 rather than dropped. This usually only matters when you’ve applied a very large negative shift — like trying to align subtitles built for a 60-second intro to a video that doesn’t have one. Multiple cues stacking at zero is the visible symptom.
We chose clamping over dropping because losing the start of the transcript is usually worse than mistiming it briefly. If you actually want to discard early cues, edit the file in any SRT editor after the shift.