SRT vs VTT: Which Subtitle Format Should You Use?
The real differences between SRT and WebVTT subtitle files, which platforms want which, and the timing and line-length mistakes that make subtitles hard to read.
SRT and VTT are both plain-text subtitle files: a list of lines, each with a start and end time. They look almost identical, and most tools accept both. The differences matter only at the edges.
The short answer
- Uploading to YouTube, Vimeo, LinkedIn or a video editor? SRT is the safe default; everything accepts it.
- Playing video on your own website with the HTML video player? Use VTT; it's the web's native format.
What actually differs
| SRT | WebVTT (.vtt) | |
|---|---|---|
| Header | none | starts with WEBVTT |
| Time format | 00:01:02,500 (comma) | 00:01:02.500 (dot) |
| Cue numbers | expected | optional |
| Positioning and styling | basic, unevenly supported | built in (position, alignment, CSS) |
Converting between them is mostly swapping the comma and the dot and adding or removing the header. The subtitle fixer converts either way.
The problems that matter more than the format
Most "broken subtitles" aren't a format problem. They're timing and readability problems:
- Overlaps: a line still showing when the next one starts. Some players drop one of them.
- Flash cues: lines on screen for less than about 0.8 s, too short to read.
- Too fast: more than roughly 17 characters per second is hard to follow.
- Long lines: more than about 42 characters per line, or more than two lines.
- Drift: subtitles that start in sync and slowly slide out, usually a frame-rate mismatch (25 vs 23.976 fps).
Those limits come from common broadcast and streaming style guides; adjust them if a client has their own spec. The subtitle fixer finds all of these, fixes what can be fixed by timing alone, and re-times drifting files from two sync points.