Convert VTT to SRT

WebVTT exists for the browser and is very good at that job, which is also its limit. Desktop players, televisions, media boxes, most hardware that reads subtitles off a USB stick, and a large share of upload forms expect SubRip and treat anything else as an unknown file. The demand for this conversion is almost entirely the same sentence in different words: the caption file works on the web page it came from and nowhere else.

The usual sources are worth naming, because they change what you should check afterwards. A VTT downloaded from a web player is likely to carry cue settings. One exported by a transcription service is likely to carry voice tags naming each speaker. One produced by a subtitle editor is usually plain, and converts to a clean SRT with nothing to clean up.

A WebVTT timing line can carry settings after the end time: a line number pushing the caption to the top of the frame, an alignment, a width. The converter reads the end timestamp up to the first space and throws the rest away, because SubRip has no syntax that could hold it.

This is the one real loss in the conversion and it is invisible in the output. If your captions were positioned deliberately — moved to the top for the few seconds a lower third is on screen, or narrowed so they do not collide with burned-in text — the SRT will look correct and will place every line at the bottom. Where positioning matters, the honest answer is to keep the VTT as the master and treat the SRT as a delivery copy for players that cannot do better.

Cue text is copied across without interpretation. That is the right behaviour for italics, which both formats spell identically, and the wrong-looking behaviour for a WebVTT voice tag, which names the speaker in angle brackets before the line. There is no equivalent construction in SubRip, so the tag is not translated, and it is not removed either.

A player will show it. The subtitle reads as the speaker name in angle brackets followed by the dialogue, which is not what anyone intended. Transcription exports are the usual source, and the fix is a search and replace over the finished SRT — either delete the tags or turn them into a spoken-name convention with a colon, which is how SubRip has always handled multiple speakers.

Which of the two to choose depends on who is watching. Deleting the tags is right for a translated dialogue track, where the speaker is visible on screen and naming them wastes a line of reading space. Converting them to names is right for anything captioned for viewers who cannot hear, and for interviews and panels where two voices alternate off camera and the audience genuinely cannot tell them apart. The tag was carrying real information in the second case, and stripping it quietly is a small accessibility regression that nobody will report.

A WebVTT file may contain comment blocks introduced by NOTE and a STYLE block carrying CSS for the cue pseudo-element. Neither contains a timestamp arrow, and the parser identifies a cue by looking for that arrow rather than by counting lines, so both are skipped rather than mistaken for text.

The practical value of that is negative space: the SRT contains only real cues, and nothing from the authoring layer of the VTT leaks into it. The corresponding cost is that any styling defined in that block is gone, which matters if it was doing something load-bearing such as making a hard-to-read colour readable. SubRip leaves every visual decision to the player by design.

WebVTT cues are usually unnumbered, and where a line does appear above the timestamp it is an identifier rather than a counter — a name a stylesheet or a script can refer to. SubRip expects a sequential number, so the converter writes one, starting at one and counting up regardless of what the source contained.

That has a pleasant side effect on files that have been edited by hand. A VTT whose identifiers are inconsistent, duplicated or missing produces an SRT numbered cleanly from beginning to end. It also means any identifier you were relying on has gone; if a script keyed off cue names, it needs a different anchor after this conversion.

Every time is held internally in milliseconds and written back out as hours, minutes, seconds and milliseconds with the hours zero-padded and a comma before the fraction. No rounding happens in either direction, so a cue that began at 00:04:12.500 in the VTT begins at 00:04:12,500 in the SRT, to the millisecond.

It is worth being precise about this because the comma is the classic reason a subtitle file is rejected after somebody edited it. Both formats measure the same thing to the same resolution; they disagree only about how to punctuate a decimal. Anything that claims a conversion between them shifts the timing is describing a different bug.

A large share of WebVTT files in circulation were produced by automatic transcription, and the conversion does not improve them. Automatic output is good enough to skim and not good enough to publish, and the words it gets wrong are disproportionately the proper nouns and the technical vocabulary that carry the meaning of the sentence.

Two mechanical faults are worth a pass as well. Machine transcripts often break lines at the point the recogniser flushed its buffer rather than at a clause boundary, and they often run cues far longer or shorter than a reader can follow. Fixing those in the SRT is easy — it is text with an obvious structure — and it is the difference between captions somebody can read and captions somebody gives up on.

Most players load a subtitle file automatically when it sits beside the video with the same base name: film.mp4 and film.srt in the same folder. A single character of difference and nothing appears, which accounts for a large share of reports that a conversion failed when it did not.

A language suffix before the extension, as in film.en.srt, is the convention when several languages are present and the common players understand it. Beyond that, televisions and media boxes are fussier than desktop software: many read subtitles only from the same partition as the video, and a good number read nothing but SubRip, which is the reason this conversion exists.

The converter refuses rather than handing back an empty SRT. If parsing a file yields nothing, that is treated as an error and stated as one, because a zero-cue subtitle file downloads perfectly, loads perfectly and shows nothing, and a viewer would reasonably conclude the video simply has no captions rather than that a conversion quietly failed.

Two causes account for most of it. The first is a file that is not WebVTT at all — a caption file renamed by somebody upstream, or an HTML error page saved with a .vtt extension, which is what a failed download from a streaming URL usually produces. The second is line endings: cues are separated by blank lines, and the parser recognises the Unix and Windows conventions. A file saved with the classic Mac carriage-return-only endings has, as far as any of this is concerned, exactly one very long line and no blank lines in it. Re-saving it from a modern editor fixes it in one step.

For the overwhelming majority of files it is exact. Text and timings are the whole content of a plain WebVTT track, and both survive to the millisecond and the character. That is why the conversion is instant and why nobody needs to check the output of it.

The exceptions are the three named above, and they are worth restating together because a converter that stayed quiet about them would be more comfortable and less useful: positioning is discarded, voice tags become visible text, and cue identifiers are replaced by numbers. If a file uses none of the three — and most do not — the SRT is the same subtitles in different punctuation.