DesiCaptionsWhy Subtitles Go Out of Sync After Export
Three different problems look identical in the preview window. The fix depends on which one you have.
Short answer
Play your exported video and look at the first caption and the last one. If both are wrong by the same amount, the whole track just needs shifting. If the first is fine and the last is far off, your video and your subtitle file disagree about the frame rate, usually 24 against 23.976. If it is wrong in random places, your video came off a phone and has a changing frame rate.
The fix that prevents all three: finish your edit first, export the video, and make the captions from that final file.
Your captions looked perfect in the editor. You exported, watched the file back, and by the ninety second mark the words are landing a beat after the speech. Or they were wrong from the very first line. Or they were fine, then slowly slid apart.
Those are three separate faults with three separate fixes, and the reason generic advice rarely helps is that it treats them as one problem. The good news is you can identify yours in about ten seconds.
Find out which one you have
Play the exported video and check the very first caption, then check the last one.
- Wrong at the start, equally wrong at the end. A constant offset. Every caption is late (or early) by the same amount.
- Right at the start, progressively wronger toward the end. Drift. This is a frame rate mismatch, and it is the most common cause by far.
- Right in places, wrong in others, with no pattern. Variable frame rate source footage, which almost always means the video came off a phone.
Measure the error at the end rather than trusting your ear in the middle. Drift of a tenth of a second per minute is invisible for the first thirty seconds and glaring by minute five.
Cause 1: frame rate mismatch (the drift)
Subtitle files store time as real clock time. An SRT cue that reads 00:00:10,000 means ten actual seconds. Video, on the other hand, is a count of frames, and the player converts frames to time using the frame rate it thinks the file has.
If a subtitle file was timed against a 24 fps assumption but the video is actually 23.976 fps, every timestamp is off by a factor of 1.001. That sounds negligible. It is one frame every 40 seconds, roughly four tenths of a second by minute ten, and about two and a half seconds across an hour. Short reels never notice. Long videos fall apart at the end.
The 23.976 versus 24 pair causes most of these, because the two numbers look interchangeable and are not. The 29.97 versus 30 pair does the same thing for the same reason.
How to fix it
- Find the true frame rate of your video. In VLC it is under Tools then Codec Information. In Premiere it is in the clip properties. Do not trust what you set in the export dialog, check what the file actually contains.
- Set your editor sequence to that exact frame rate before importing the subtitle file.
- If the subtitles are already misaligned, most editors can stretch a subtitle track by a ratio. Multiply every timestamp by 24/23.976 (or the inverse, depending on direction) rather than nudging cues by hand.
The durable fix is to stop the mismatch happening: generate your captions from the same file you are going to publish, after any frame rate conversion, not from an earlier version of it.
Cause 2: variable frame rate footage (the random one)
Phones do not record at a steady frame rate. To hold exposure in changing light, an iPhone or Android camera quietly varies how many frames it captures per second, which is why a file will report something like 29.4 fps rather than a round number. This is called variable frame rate, or VFR.
Subtitle timings assume time flows evenly. Against VFR footage it does not, so captions land correctly during the parts filmed in steady light and wander during the parts where the camera changed its rate. There is no single offset that fixes it, because the error is not constant.
How to fix it
- Convert the source to constant frame rate before you do anything else. In HandBrake, set Framerate to a fixed value such as 30 and pick Constant Framerate rather than Variable.
- With ffmpeg the equivalent is a re-encode with an explicit rate:
ffmpeg -i input.mp4 -r 30 -c:v libx264 -crf 18 -c:a copy output.mp4 - Generate the captions from the converted file, not the original.
This is the single most common cause for creators working from phone footage, and it is the one people waste the most time on, because nudging the offset appears to fix it for the section they are watching.
Cause 3: a constant offset (the easy one)
If every caption is late by the same amount, something added or removed time at the front. Usually that is a trimmed intro, a title card inserted after captioning, or a subtitle file generated from an audio-only export that started at a different point than the video.
Fix it by shifting the whole track. VLC will do it live during playback with the G and H keys, which is the fastest way to measure exactly how far out you are. Once you know the number, apply that shift to the file itself in your editor or subtitle tool, then re-export.
If you are working in Roman-script Hindi or Hinglish captions, avoid retyping timestamps by hand at this stage. It is slow and it introduces new errors. Shift the whole track by a measured amount instead.
How to measure the offset exactly
Guessing at the number is what turns a five minute fix into an evening. There is a precise way to do it, and it needs nothing but VLC.
- Open the video in VLC with the subtitle file loaded. Drag the .srt onto the playing video if it does not load by itself.
- Find a moment where someone starts a sentence clearly. A hard consonant is easiest to hear.
- Play it and press G to move subtitles earlier or H to move them later. Each press is 50 milliseconds.
- Count your presses until the caption lands on the speech. Ten presses of H is 500 milliseconds late.
- VLC shows the total in the corner as you go. That number is your offset.
Now check the same thing near the end of the video. If the offset there is the same, you have a constant offset and one shift fixes everything. If it has grown, you have drift, and the ratio between the two numbers tells you the frame rate error.
VLC only changes playback, not the file. Once you know the number you still have to apply it in your editor or subtitle tool and re-export, or the fix disappears the moment anyone else opens it.
Four things that make it worse
Some common instincts actively damage the situation.
- Nudging cues one at a time. If the cause is drift, fixing the middle breaks both ends. You will spend an hour and finish further from correct than you started.
- Re-exporting the video at a different frame rate to match the subtitles. This changes the video and usually introduces judder. Fix the subtitle timings instead, they are text.
- Trimming the video after captioning. Every cue after the cut is now wrong by the length of what you removed. Cut first, caption second, always.
- Editing timestamps by hand in a text editor. Fine for two cues. For two hundred, you will introduce more errors than you remove, and you lose word-level timings entirely.
Platform quirks worth knowing
Even a correct file can behave differently once uploaded.
YouTube
YouTube re-encodes everything you upload, but it does not re-time your subtitle track, so a correctly timed SRT stays correct. If captions look wrong on YouTube but right locally, the usual cause is that you uploaded a different cut than the one you captioned.
Instagram and TikTok
Neither accepts a subtitle file for short-form, so sync problems here are only possible with burned-in captions, and burned-in captions cannot drift. If your Reel captions look off, it is a placement problem rather than a timing one, which is covered in our guide to the Reels safe area.
Editors
Premiere, Final Cut and Resolve all read the sequence frame rate rather than the file. Importing an SRT into a sequence set to the wrong rate reproduces the drift inside your project even when the file is perfect.
The workflow that avoids all three
Every one of these faults comes from the same root: the captions were timed against a different file than the one you published.
- Finish your edit first. Cuts, trims, title cards, speed ramps, all of it.
- Export the final video.
- Convert to constant frame rate if the footage came from a phone.
- Generate captions from that final file.
- Burn them in, or import the subtitle file into a sequence set to the same frame rate.
Captioning last feels backwards if you are used to scripting first, but it removes the entire category of sync bugs. It is also why burned-in captions never drift: the words are pixels in the video, so there is no separate clock to disagree with.