Subtitle sync
Shift the timings, stretch them when the subtitles drift, and check that a viewer can actually read them. The file is read in your browser and never uploaded.
Choose an SRT or VTT file
or drop it here. It stays in your browser.
or paste the subtitles instead
Shift every cue
Negative makes subtitles appear earlier. Use this when they are late by a constant amount all the way through.
Framerate
Use this when the subtitles start in sync and drift further out as the film goes on. No amount of shifting fixes drift.
Save as
SRT for most players and uploads. VTT for HTML5 video and web players.
Late is not the same problem as drifting
Out-of-sync subtitles have two completely different causes, and the fix for one does nothing for the other. Almost every online subtitle tool only offers the first.
Constant offset: they are late, evenly
The subtitles are 2 seconds behind at the start, 2 seconds behind in the middle, and 2 seconds behind at the end. Usually a different release of the same film with a longer intro, or a player that starts counting from a different point.
Fix: shift. Add or subtract the same amount from every timestamp. That is the box at the top and it is all most people need.
Framerate mismatch: they drift
The subtitles are perfect for the first minute, a second out after ten, and half a minute out by the end. This is the one that makes people give up, because every offset they try is wrong somewhere else.
The cause is a framerate difference. Film is mastered at 23.976 fps and European broadcast at 25 fps, and a subtitle file timed for one played against the other runs about 4% fast or slow. That is roughly 2.5 seconds of error per minute — imperceptible at the start, unwatchable by the end.
Fix: stretch. Multiply every timestamp by the ratio between the two framerates rather than adding to it. Shifting cannot do this, which is why so many attempts to fix drift by hand fail.
Telling them apart in ten seconds
Note how far out the subtitles are near the beginning, then near the end. If the error is the same in both places it is an offset. If it roughly doubles when you are twice as far in, it is proportional, and you need the stretch.
Both can apply at once. This tool scales first and shifts second, which is the order that matches what people mean: the offset is not itself stretched.
The check nobody runs: reading speed
Timing is only half of whether a subtitle works. The other half is whether there is time to read it, and that has nothing to do with sync. A cue can sit exactly on the audio, be spelled correctly, be positioned perfectly, and still be wrong, because speech is faster than reading.
The measure is characters per second: the visible text divided by the time it is on screen. It is the most common reason a subtitle file is rejected in professional QC and the least visible on inspection, which is a bad combination. Nothing about a file looks wrong when its reading speed is wrong.
Where the limits come from
The numbers offered here are the published Netflix limits, because they are the ones most widely adopted as a house style: 20 CPS for adult English, 17 for most Latin-script languages and for children's content. The 20 is stated in Netflix's English timed text style guide; the others come from its per-language guides. Full-width scripts sit much lower, because a character carries more meaning: 12 for Korean, 9 for Chinese, 4 for Japanese. Alongside the speed comes a timing envelope: a minimum of five sixths of a second on screen, a maximum of seven, a two frame gap between cues, and at most two lines of 42 characters.
Formatting tags are stripped before counting, since the viewer never reads them, and a line break counts as the single space it stands in for. That last one is a judgement call and tools differ on it by a character or two per line.
Why the check runs on the output, not the input
A shift changes no durations, so it changes no reading speeds. A framerate stretch changes every duration, so it changes every reading speed. Correcting drift can therefore create a reading speed problem that was not in the original file, and correcting it the other way can hide one. So the check here always runs on the cues as they will be written out, which means the report can never describe a different file from the one you save.
Terminology
- CPS
- Characters per second. Visible characters in a cue divided by its duration in seconds. The standard measure of subtitle reading speed.
- Cue
- One subtitle: a start time, an end time and the text shown between them.
- SRT
- SubRip. Numbered cues, comma before the milliseconds. The most widely accepted format for players, televisions and upload forms.
- VTT
- WebVTT. A
WEBVTTheader, no numbering, full stop before the milliseconds, and support for positioning. Required by HTML5 video. - 23.976 fps
- The film standard, being 24 fps slowed by a factor of 1000/1001. Its mismatch with the 25 fps broadcast standard is the single most common cause of subtitle drift.
Questions about subtitle timing
My subtitles are a few seconds late the whole way through
That is a constant offset, and it is the easy case. Put the delay into the shift box as a negative number to make the subtitles appear earlier, or positive to make them appear later.
If they are 2.4 seconds late, enter -2.4. Every cue moves by the same amount and the file is otherwise untouched.
They start in sync but drift further out as the film goes on
That is a framerate mismatch, and shifting cannot fix it. No single offset works, because the error grows as the film plays.
It happens when subtitles timed for one framerate are played against a different encode of the same film. A 23.976 fps subtitle shown at 25 fps runs about 4% fast, which is roughly 2.5 seconds of drift for every minute. By the end of a two hour film it is minutes out.
Pick the framerate pair from the dropdown. That multiplies every timestamp instead of adding to it, which is what actually corrects drift.
How do I know which framerate to pick?
Work it out from the drift rather than guessing. Note how far out the subtitles are near the start and how far out they are near the end.
If the error roughly doubles when you get twice as far into the film, it is proportional, so it is a framerate problem. The most common pair by a wide margin is 23.976 to 25 or the reverse: 23.976 is the standard for film-sourced video, 25 for European broadcast.
The tool tells you how far it moves the last cue, so you can compare that against the drift you actually observed.
What is the difference between SRT and VTT?
Almost nothing that matters for timing. SRT numbers each cue and separates the seconds from the milliseconds with a comma. VTT starts with a WEBVTT header, drops the numbering, and uses a full stop instead.
Use SRT for desktop players, TVs and most upload forms. Use VTT for HTML5 <video> and web players, which will not accept SRT. Converting between them here is just a change of format button; the timings are identical.
What is CPS, and what is a safe reading speed?
Characters per second. It is the visible text of a cue divided by how long it stays on screen, and it is the number professional subtitle QC rejects files on more often than any other.
The published Netflix limits are 20 CPS for adult English and 17 CPS for most Latin-script languages and children's content. Full-width scripts are far lower because each character carries more meaning: 12 for Korean, 9 for Chinese, 4 for Japanese. Formatting tags are not counted here, because the viewer never reads them.
My subtitles are timed correctly but still feel rushed
Then the timing is not the problem, the reading speed is. A cue can sit exactly on the audio and still be unreadable, because speech is faster than reading.
This is the failure that is invisible on inspection: the file is spelled correctly, spotted perfectly, and still fails QC. Pick a house style in the check and the tool lists the worst offenders fastest first. Fixing the top few usually fixes the pattern, because they tend to share a cause.
Does retiming a file break its reading speed?
A shift does not. Moving every cue by the same amount changes no duration, so no reading speed changes.
A framerate stretch does, and this catches people out. Speeding a file up by 4% shortens every cue by 4%, so borderline cues cross the limit. That is why the check here runs on the cues as they will be saved rather than as they were loaded: fix the drift and you may have introduced a reading speed problem that was not there before.
What does closing overlapping cues do?
It trims the end of any cue that runs into the next one, leaving a two frame gap. Only dead time is removed; the words are never changed, which makes it the one subtitle repair that is pure arithmetic with no editorial judgement in it.
Where two cues overlap so badly that trimming would leave nothing on screen, the cue is left alone and counted separately. That case needs the text merged or cut by a person, and quietly collapsing it to zero length would be worse than reporting it.
Does my file get uploaded?
No. It is read with the browser File API into memory on your own machine, transformed there, and handed back as a download. There is no server to send it to; this site is static files.
That matters more than it sounds for subtitles, which are frequently unreleased material, client work, or a translation somebody has not published yet.
Will it keep my styling and positioning?
VTT cue settings after the end timestamp, such as line:90% or align:start, are preserved when you save as VTT. Inline tags inside the cue text are passed through untouched.
STYLE, REGION and NOTE blocks are skipped rather than rewritten. Converting VTT to SRT necessarily drops positioning, because SRT has nowhere to put it.
What happens if a cue ends up before zero?
It gets clamped to 00:00:00 and the tool tells you how many cues that affected. A negative timestamp is not representable in either format, and silently wrapping it around would produce a file that looks fine and plays wrongly.
If you see that warning, the shift is larger than the time before the first cue. Use a smaller one, or trim the leading cues.
Can it handle a large file?
Yes. Subtitles are small even for a long film: a two hour feature is typically 1,500 to 2,500 cues and well under a megabyte. The whole transformation is string arithmetic and finishes instantly.
Line endings are normalised on the way in, so files from Windows, macOS and Unix all behave the same, and a byte order mark is stripped rather than treated as part of the first cue.
Notes
SRT is a de facto format with no formal specification; the parser here accepts the variations that occur in practice, including missing cue numbers, an hours field that is absent or more than two digits, and any of the three line ending conventions.
WebVTT is a W3C standard. Cue settings are preserved on a VTT to VTT save and necessarily dropped when converting to SRT, which has no way to express them.
The reading speed limits, the 42 character line length, the two line maximum and the five sixths of a second to seven second duration envelope are the figures published in the Netflix Timed Text Style Guide, which is the most widely adopted subtitle house style and the reason those numbers appear in most other guidance. The two frame minimum gap is framerate dependent; it is applied here as 80 ms, which is two frames at 25 fps.
Nothing is uploaded and nothing is stored. If a file fails to parse here that a player accepts, send it to me and the parser gets fixed.