Turn WebVTT (.vtt) subtitles into SBV (.sbv) subtitles in a few clicks—fast, simple, and right in your browser.
HH:MM:SS.mmm --> HH:MM:SS.mmm arrow timing is rewritten to YouTube's H:MM:SS.mmm,H:MM:SS.mmm comma form, the WEBVTT header is dropped, optional cue identifiers are stripped, and inline tags such as <b>, <i>, <c.classname>, and <v Speaker> are removed because SBV does not support markup..sbv file individually or as a ZIP. UTF-8 encoding is preserved so non-Latin scripts (Japanese, Arabic, Cyrillic, Devanagari) survive the round trip..sbv. SBV is one of the basic caption formats YouTube officially accepts alongside SRT and SUB.WebVTT (.vtt) is the W3C standard for HTML5 <track> captions and ships with rich features — cue identifiers, positioning (line:, position:, align:), STYLE blocks, voice spans (<v Speaker>), and class tags. SubViewer (.sbv), the format YouTube's auto-caption tool exports, is the opposite: timestamp line, text line, blank line, repeat. No header, no IDs, no styling. Converting strips the formatting WebVTT carries that SBV cannot represent, and rewrites the timestamp punctuation YouTube's parser expects.
WEBVTT first line, or on cue settings appended to the timestamp arrow. SBV's text-line-only layout sidesteps both..sbv is roughly 10–20% smaller than the equivalent .vtt (no header, no IDs, no markup), useful when batching hundreds of caption files into an email or chat attachment.If you need the reverse, see SBV to VTT. For broader subtitle workflows, VTT to SRT is the safer choice for non-YouTube uploads, and VTT to TTML handles broadcast/DFXP-style pipelines.
| Property | WebVTT (.vtt) |
SubViewer (.sbv) |
|---|---|---|
| Standardized by | W3C Timed Text Working Group (current Candidate Recommendation, May 2026) | De facto standard via YouTube's caption tooling; based on SubViewer 1.0/2.0 |
| Required header | WEBVTT on line 1 |
None |
| Timestamp syntax | HH:MM:SS.mmm --> HH:MM:SS.mmm (arrow separator, period for ms) |
H:MM:SS.mmm,H:MM:SS.mmm on its own line (comma separator) |
| Cue identifiers | Optional (any string before the timing line) | Not supported |
| Inline styling | <b>, <i>, <u>, <c.classname>, <ruby>, <v Speaker>, STYLE blocks with CSS |
None — plain text only |
| Positioning / alignment | line:, position:, align:, vertical: cue settings |
None |
| File encoding | UTF-8 (mandatory) | UTF-8 (de facto) |
HTML5 <track> support |
Native in all major browsers | Not supported — requires conversion |
| YouTube acceptance | Yes (listed under Advanced formats) | Yes (listed under Basic formats; YouTube's own export) |
| Best for | Web video, HTML5 players, accessibility metadata, chapter tracks | YouTube caption editing, legacy SubViewer pipelines, minimal text-only handoffs |
VTT carries information SBV's grammar cannot hold. The converter discards these and keeps the rest:
| VTT feature | Survives in SBV? | Notes |
|---|---|---|
| Cue timing (start/end) | Yes | Rewritten from --> arrow to comma separator |
| Plain caption text | Yes | UTF-8 preserved, line breaks kept |
| Cue identifiers (the optional label before timing) | No | Stripped — SBV has no equivalent |
WEBVTT header and NOTE blocks |
No | Dropped |
Inline tags (<b>, <i>, <c>, <v>, <ruby>) |
No | Tag wrappers removed; inner text preserved |
| STYLE blocks (CSS) | No | Removed; not representable in SBV |
Cue settings (line:, position:, align:, size:, vertical:) |
No | Discarded; SBV has no positioning model |
Chapter / NOTE / REGION blocks |
No | Removed |
If you need any of the lost features downstream, keep your VTT master and only ship SBV as the YouTube-facing copy.
Yes. YouTube Help lists SubViewer (.sbv or .sub) among its "Basic" supported caption formats, alongside SRT, MPsub, LRC, and Videotron Lambda. You upload it from Subtitles → "Upload file → With timing" in YouTube Studio. If timing offsets are off after upload, that's almost always a frame-rate / NDF-vs-DF timecode issue in the source, not the SBV format itself.
SBV inherits its grammar from the original SubViewer player, which predates WebVTT and SRT's de facto standardization. The single-line start,end form was simpler to parse on early-2000s hardware and stuck around when YouTube adopted it for auto-caption exports. There's no technical advantage today — it's a compatibility artifact.
No — SBV has no syntax for inline formatting. Bold, italic, color classes, ruby annotations, and voice-spans are all stripped during conversion because there's no SBV equivalent. The plain text inside the tags is preserved. If you need formatting, convert to VTT, ASS, or TTML instead.
No. SBV has no positioning model — every line renders at YouTube's default location. Cue settings like line:50%, position:25%,start, align:left, and vertical:rl are discarded. For positioned captions, stick with VTT or use VTT to ASS, which preserves alignment via ASS override tags.
No. SBV files have no cue numbering — cues are separated by blank lines only. Adding numbers would actually break YouTube's SBV parser, which expects the timestamp line to come first in every cue. If you want numbered cues, convert to VTT to SRT instead.
Yes. Both formats are UTF-8 by convention, and the converter passes the byte stream through unchanged for the text content. Japanese, Korean, Chinese, Arabic, Hebrew, Cyrillic, Devanagari, Thai, and emoji all survive. If your VTT was saved as UTF-16 or Windows-1252, decode it first — SBV consumers (YouTube included) expect UTF-8.
Yes. Drop multiple .vtt files at once and they're converted in parallel in your browser session. The result is downloadable as individual .sbv files or as a single ZIP. There's no per-file cap beyond available browser memory — typical caption files are 5–50 KB so thousands fit comfortably.
SRT is the safer default. YouTube accepts both, but SRT is also accepted by virtually every other platform (Vimeo, social uploads, Premiere, Final Cut, DaVinci Resolve, Netflix delivery specs), so an SRT master converts more cleanly into anything else later. Use SBV when you need to match an existing YouTube workflow file or a legacy SubViewer-based translator pipeline.
No. The conversion runs entirely in your browser via JavaScript — your file never leaves the device. No account, no watermark, no per-file size cap, and no Pro tier gating multi-file batches. Close the tab and the file is gone from session memory.