Convert SRT to SBV

SBV is Google’s own caption format, produced by YouTube’s caption editor since 2008 and offered by its download tool beside SubRip and WebVTT. Essentially nothing outside that ecosystem writes it and very little reads it, which makes it the narrowest format in this bundle and the one with the clearest single home.

The point worth making before anything else is that YouTube accepts SubRip. If the goal is captions on one video, uploading the SRT you already have is fewer steps and fewer chances to introduce a fault. This conversion earns its place when something other than the upload form wants SBV, and the next section names what that usually is.

The common one is an archive. A channel that has been captioning for years, or an agency managing several, tends to have hundreds of files in whatever the editor exported, and a new episode arriving as an SRT is the odd one out. Converting it in keeps one directory in one format, which is worth more than saving a conversion step.

The second is tooling. Because SBV has no header, no numbering and no styling, a line of it is trivially parseable: two timestamps and a comma. Scripts, spreadsheets and quality-check tools written around the editor’s export tend to assume exactly that shape, and handing them an SRT with its numbering and its arrow means changing the tool rather than the file.

The third, and the one people mention least, is that the caption editor is genuinely better than a text file for timing work. Correcting words is faster offline; correcting where a caption starts is faster against a waveform and a video you can scrub. A team that does the wording pass in a document and the timing pass in the editor needs the file to move in both directions, and SBV is the format that side of the workflow speaks.

Three things, all of them structural rather than semantic. The cue number on its own line disappears. The arrow between the two timestamps becomes a comma. And the timestamps themselves are rewritten in the SBV convention rather than the SubRip one. The text, the line breaks within it and the timings to the millisecond are untouched.

That is why this conversion is exact where it matters. Both formats hold the same thing — a start, an end and some words — and disagree only about punctuation and ceremony. Nothing has to be approximated, rounded or discarded, which is not true of most pairs on this site.

SubRip writes the hour with two digits: 00:04:12,500. SBV writes it with as many digits as it needs: 0:04:12.500. That single leading zero is the difference between a file YouTube accepts and one it refuses, and it is the reason renaming an SRT to .sbv has never worked for anyone.

The milliseconds are the other half. SubRip separates them with a comma and SBV with a full stop, which is the same disagreement WebVTT has with SubRip and in the same direction. Both are written correctly here, three digits of milliseconds after a full stop, so the file is well-formed the moment it downloads.

SubRip numbers every cue from one, and the number is part of the format rather than a courtesy — a strict parser expects it. SBV has no numbering whatsoever: a timing line, one or two lines of text, a blank line, and the next entry starts.

The numbers are read from the SRT and then simply not written. That is not a loss, because nothing in SBV or in YouTube refers to them, and leaving them in would be worse than dropping them: a stray number above a timing line reads as caption text to a parser that was not expecting it, and the caption appears on screen as a digit.

SBV carries a start time, an end time and words. No italics, no bold, no colour, no positioning, no way to mark who is speaking. It is simpler even than SubRip, which at least has a convention for italics that most players honour.

Cue text is copied verbatim, so any angle-bracket tag in the source survives into the SBV as literal characters, and YouTube will display it. A track that leans on italics for internal monologue or on-screen text needs those tags removed before conversion, and the meaning re-expressed in words or punctuation if it mattered. Strip them in the SRT rather than in the SBV, so the master file stays the clean one.

Square brackets are the convention that fills the gap, and it is the one broadcast captioning settled on long ago: a bracketed note for a sound, a speaker or a piece of context that the dialogue does not carry. It costs characters on screen, which is why a styled format avoids it, and it is understood by every viewer without being explained. For anything that has to survive a format with no styling at all, that is worth more than an italic nobody will see.

Line breaks inside a caption survive the conversion as real line breaks, which is what SBV expects: the text simply occupies two lines between the timing line and the blank line. Nothing needs escaping and nothing is joined.

Speaker attribution is the gap. There is no construct for it, so the convention is a name and a colon typed into the text, or a dash at the start of each speaker’s line as broadcast captioning has always done. If your SRT used a voice convention already, it carries across unchanged; if it relied on colour to distinguish two speakers, that information does not exist in either format and has to be rewritten as words.

The output is written as UTF-8, which is what YouTube expects and what makes accented characters and non-Latin scripts survive the upload. SubRip has no way to declare its own encoding, so the conversion is a reasonable moment to settle the question rather than leaving it to a guess.

When an upload is rejected after a round of hand-editing, the cause is almost always one of three things: a timestamp that acquired padding or a comma, a blank line between entries that went missing, or the file having been saved in a regional encoding by an editor that defaults to one. YouTube’s error message is not specific enough to distinguish them, so check all three.

SubRip gives a parser three signals that a new subtitle has begun: a blank line, a number on its own, and a timing line with an arrow in it. Lose one and the other two still work. SBV has exactly one signal, the blank line between entries, and a timing line is recognised only by being the first line of a block and containing a comma.

That makes the blank line load-bearing in a way it is not in SubRip. Remove one while editing — easily done when merging two captions and tidying up afterwards — and the two entries become a single block whose second timing line is read as caption text. YouTube will either reject the file or display a timestamp on screen, and neither outcome points at the missing line. When correcting an SBV by hand, treat the blank lines as structure rather than as whitespace.

SubRip is what every subtitle editor handles well, what every player reads and what almost every platform accepts. SBV reads essentially nowhere outside YouTube and carries nothing SubRip does not. As a working file it has no advantages, and as an archive format it ties a set of captions to one company’s tooling.

The arrangement that survives contact with a real workflow is to correct and time in SRT, keep that file, and convert at the point a particular destination asks for something else. Two hand-maintained copies of the same captions drift apart the first time somebody fixes a typo in whichever one they had open, and nothing in either file records which of them is now right.