SRT → WebVTT
Convert an SRT subtitle file to WebVTT so an HTML <video> will actually show it. Runs in your browser. Covers the header, the comma, the MIME type and the encoding.
Runs in your browser
Negative makes the subtitles appear earlier. Cues that would go before zero are clamped to zero rather than dropped.
Not carried across
Parsed and written in your browser. The file is never uploaded.
Why the conversion is needed at all
A browser will not read an SRT file. The <track> element accepts exactly one subtitle format,
WebVTT, and everything else is ignored — silently, with no console error and no visible failure.
A video that plays with no subtitles and no complaint is almost always this.
The two formats are otherwise the same idea, which is why renaming the file feels like it ought to work. It does not, for three reasons:
| SRT | WebVTT | |
|---|---|---|
| First line | the number 1 | the word WEBVTT |
| Timestamp | 00:01:02,500 | 00:01:02.500 |
| Cue numbers | on every cue | not used |
Paste the file above, or pick it with the file button, and you get a .vtt back. Nothing is
uploaded.
The header is not decoration
A WebVTT file whose first characters are not WEBVTT is not a WebVTT file, and the spec requires
the browser to abort parsing right there. It is the single most common reason a converted file
still shows nothing.
The comma is the other half. 00:00:01,000 is a parse error in WebVTT, and one bad timestamp
kills its cue rather than the file — so a hand-edited file can lose a few lines and keep the rest,
which is much harder to notice than losing all of them.
Putting it on a video
<video controls crossorigin="anonymous">
<source src="film.mp4" type="video/mp4" />
<track kind="subtitles" src="film.vtt" srclang="en" label="English" default />
</video>Three things outside the file itself will stop this working:
- Serve it as
text/vtt. A server that sends.vttasapplication/octet-stream, or astext/plain, gets the track rejected.text/vttis the registered type. file://will not do. A<track>is subject to the same-origin policy, and a page opened from disk fails it. Any local web server is enough.- Cross-origin needs both ends. Subtitles on another domain need
Access-Control-Allow-Originfrom that domain and acrossoriginattribute on the<video>. One without the other fails.
default picks the track; without it the visitor has to choose from the player menu, and most
never look.
Encoding, which bites Chinese subtitles hardest
WebVTT files must be UTF-8. The spec has no encoding declaration and no fallback — there is nothing you can put in the file to say otherwise.
SRT has no such rule, so SRT files in the wild are in whatever the machine that saved them used:
Big5, GB18030, Shift-JIS, Windows-1252. A Chinese subtitle file downloaded from a forum is very
often Big5, and converting it byte-for-byte produces a valid .vtt full of 亂碼.
This page reads files as UTF-8. If the preview above is already mojibake, the file was not UTF-8 and no amount of converting will fix it — re-save it as UTF-8 first, in a text editor that lets you choose the encoding, and then convert.
What the conversion changes
Almost nothing, which is the point. Timing is identical to the millisecond, the text is copied
through, and <i>, <b> and <u> are spelled the same way in both formats and survive.
Cue numbers are dropped, because WebVTT does not use them. Cue identifiers — an optional name on the line above the timing — are dropped too; nothing outside WebVTT’s own CSS reads them.
Going the other way is just as lossless, except for WebVTT cue settings like
align:start position:10%, which SRT has no way to express.
Related
The full subtitle converter also writes ASS and shifts the whole timeline when subtitles are out of sync, and ASS to SRT handles files that arrive from a fansub group.