XConvert
Downloads
Pricing

Convert TXT to SBV Online

Turn a TXT subtitle file into SBV format in seconds—right in your browser for quick uploads and downloads.

Input (TXT)
Output (SBV)

How to Convert TXT to SBV Online

  1. Upload Your TXT File or Paste Text: Drag and drop a .txt transcript, click "Add Files" to browse, or paste lines directly into the editor. The file is parsed in your browser — nothing is uploaded to a server. Batch is supported, so a whole folder of YouTube scripts can be processed at once.
  2. Pick the Input Mode: The converter auto-detects whether your TXT is plain text (one caption per line, no timestamps) or timecoded text (lines already paired with H:MM:SS markers). For plain text, the default duration per cue is 2.5 seconds and cues are laid end-to-end with no gap. For timecoded text, the parser accepts mixed millisecond separators (., ,, or :) and normalises every cue to the period-millisecond grammar SBV requires.
  3. Confirm Output Encoding (Optional): Output is plain UTF-8 with no BOM by default — exactly what YouTube's supported-formats page mandates for SubViewer basic files. UTF-8-with-BOM is available if you need to edit the file later in a legacy Windows tool that misreads BOM-less text.
  4. Convert and Download: Click Convert. The converter rewrites each timecode to H:MM:SS.mmm,H:MM:SS.mmm (period before milliseconds, comma between start and end — the SBV signature) and saves the file as yourscript.sbv. No sign-up, no watermark, no email.

Why Convert TXT to SBV?

TXT is a plain-text transcript — words on a page with no concept of time. SBV (SubViewer) is YouTube's house caption format: each cue is a single timestamp line in the form H:MM:SS.mmm,H:MM:SS.mmm, the caption text directly below, and a blank line between cues. There are no sequence numbers, no styling tags, no header — the parser is the simplest of any modern caption format. YouTube's help docs list SubViewer (.sbv or .sub) as a "basic" caption file and require plain UTF-8. The conversion adds the timing skeleton SBV needs so a transcript can ride along with a YouTube video. Common reasons:

  • YouTube Studio caption uploads — When you download captions from YouTube Studio (Subtitles → three-dot menu → Download), the file you get is SBV. Round-tripping an edited transcript back to YouTube in the same format avoids accidental sequence-number or styling rewrites that can creep in via SRT exports.
  • Working with YouTube's auto-generated captions — YouTube's automatic speech-recognition pass produces an SBV under the hood. Editors who clean up the auto-captions in a text editor often save back to SBV so the file YouTube ingests is byte-compatible with the one it emitted.
  • Lightweight scripting and bulk edits — SBV's minimalism (no cue numbers to renumber, no <i> tags to escape) makes it the easiest format to generate from a Python or Node script, or to grep/sed in bulk. A 500-line awk one-liner that mangles SRT will usually leave SBV intact.
  • Accessibility and FCC/ADA caption compliance for YouTube videos — WCAG 2.1 success criterion 1.2.2 requires synchronised captions for prerecorded video. An SBV uploaded to YouTube satisfies the requirement on YouTube's player; a plain TXT transcript does not.
  • Translating a script in CAT tools, then re-timing — Translators work in TXT inside memoQ, Trados, or Smartcat, then need to push timed captions back to YouTube. Converting the translated TXT directly to SBV skips the SRT detour and keeps the file in YouTube's native flavour.
  • Educational platforms that ingest SBV — A handful of LMS and educational-video tools (notably Amara's YouTube workflow and some Khan Academy import paths) accept SBV directly because they treat YouTube as their source-of-truth captions store.

TXT vs SBV — Format Comparison

Property TXT (transcript) SBV (SubViewer)
Origin Generic plain text, pre-dates personal computing SubViewer player conventions, adopted by YouTube around 2008
Timecodes None (unless ad-hoc) Required: H:MM:SS.mmm,H:MM:SS.mmm on a single line
Millisecond separator N/A Period . (SRT uses comma; SBV uses period)
Start/end separator N/A Comma , (SRT uses -->)
Cue numbering None None — SBV has no sequence numbers
Block separator Newline Blank line between cues
Style markup None None — SBV does not recognise <i>, <b>, colour, or position tags
Header None None — file starts directly with the first timestamp line
Encoding Anything (often ANSI/Windows-1252) YouTube requires plain UTF-8
MIME type text/plain No registered MIME type; commonly served as text/plain
Native platforms Note apps, docs, transcript downloads YouTube Studio (upload + download), Amara, some LMS imports
Typical use Reading, indexing, search, archive YouTube captions specifically

SBV vs SRT vs VTT — Which Should You Pick?

SBV (SubViewer) SRT (SubRip) VTT (WebVTT)
Timestamp grammar H:MM:SS.mmm,H:MM:SS.mmm HH:MM:SS,mmm --> HH:MM:SS,mmm HH:MM:SS.mmm --> HH:MM:SS.mmm
Millisecond separator Period Comma Period
Sequence numbers No Yes (required) No
Header line None None WEBVTT required
Style markup None <b> <i> <u> <font color> (player-dependent) CSS-style ::cue plus <c> tags
Standards body None (YouTube convention) None (SubRip 2000) W3C
Best for YouTube workflows where the source is already SBV Cross-platform interchange — every NLE, every player HTML5 <track> on your own website
File picker shows .sbv (sometimes .sub) .srt .vtt

Frequently Asked Questions

What is the SBV format and how is it different from SRT?

SBV (SubViewer) is YouTube's lightweight caption format. A cue looks like 0:00:01.000,0:00:03.000 on one line followed by the caption text on the next — no sequence number, no styling, no header. SRT in contrast requires a sequence number above every cue and uses --> between start and end times. The two formats also disagree on the millisecond separator: SBV uses a period (.000), SRT uses a comma (,000). A YouTube uploader who edits an auto-generated SBV in a text editor will see this; opening the same file as SRT will fail to parse.

Will YouTube accept the SBV this tool produces?

Yes. YouTube's supported subtitle and caption files page explicitly lists SubViewer (.sbv or .sub) as a basic caption format. Upload via YouTube Studio → your video → Subtitles → Add language → Upload file → "With timing" → select the .sbv. YouTube requires plain UTF-8 with no style markup — which is exactly what the converter outputs by default. Captions normally appear within a few minutes after processing.

Why are my SBV captions failing to upload with "Unknown subtitle file format"?

The most common cause is stray spaces after colons in timestamps — 0: 00: 56.850 instead of 0:00:56.850. YouTube's parser is strict; a single misplaced space anywhere in the timestamp line invalidates the cue and the upload returns a generic "Unknown subtitle file format" error. This converter writes timestamps without spaces. If you hand-edited the file afterwards in a word processor with autocorrect on, that's almost certainly where the spaces crept in — re-run the conversion from the original TXT, or open the SBV in a plain editor like VS Code or Notepad++ and search-replace : with :.

What's the millisecond separator difference between SBV, SRT, and VTT?

SBV and VTT both use a period (0:00:01.500 / 00:00:01.500); SRT uses a comma (00:00:01,500). This is the single character most likely to break a subtitle file when you rename .sbv to .srt or vice versa and try to upload. WebVTT, designed later by the W3C for the HTML5 <track> element, deliberately chose the period — partly to align with ISO 8601's decimal convention and partly because SubRip's comma never made it into any standard.

How does the converter decide where each caption starts and ends when my TXT has no timestamps?

In plain-text mode, the converter assigns a default duration per line (2.5 seconds is the editorial sweet spot — fast enough to follow speech, slow enough to read) and lays cues back-to-back with no gap. The first cue starts at 0:00:00.000. After conversion, open the file in a subtitle editor like Subtitle Edit or Aegisub and nudge timings to match the actual audio. This auto-timing is a starting point, not a final sync — the BBC subtitle guidelines suggest 160-180 words per minute as a comfortable reading speed, which a 2.5-second cue at roughly 6-7 words lands inside.

Can I keep speaker labels like "JOHN:" or >> ALICE in the output?

Yes. YouTube's own SBV examples use a >> SPEAKER NAME: convention at the start of the caption text line, and the format passes anything on the text line through verbatim. The converter preserves speaker labels, bracketed stage directions, and parenthetical sound cues exactly as they appear in your TXT source. If you want each speaker on its own visual line within a single cue, put them on consecutive lines in the source TXT (separated by a single newline, not a blank line — a blank line begins a new cue).

Why are my non-Latin characters (Cyrillic, Arabic, CJK, accents) showing up as ??? after conversion?

Almost always a source-file encoding issue, not an output issue. If your original TXT was saved as ANSI / Windows-1252 / GB18030 / Shift-JIS, the bytes for those characters are already garbled before the converter sees them. Re-save the TXT as UTF-8 from VS Code, Notepad++, or Sublime (File → Save with Encoding → UTF-8), then re-run the conversion. SBV output is always UTF-8 by default, which is what YouTube's basic-format spec mandates.

Should I use SBV or SRT for my YouTube uploads?

If your source is already SBV — for example, you downloaded the auto-generated captions to clean them up — stay in SBV; round-tripping minimises diffs. If you're authoring from scratch and might also publish the captions to Vimeo, TikTok, LinkedIn, a podcast platform, or a Plex sidecar file, pick SRT — every other platform accepts SRT, but most do not accept SBV. YouTube accepts both equally well, so the choice depends on where else the file needs to go.

How long can each caption be on screen?

There is no hard SBV-format limit, but readability is the constraint. Industry guidance from the BBC subtitle guidelines and Netflix Timed Text Style Guide is roughly 160-180 words per minute, two lines per cue, a maximum of 42 characters per line, and 1-6 seconds of display time per cue. The default 2.5-second cue in plain-text mode sits inside that range for a typical short sentence. For dialogue-heavy scripts, raise the per-line duration; for fast Q&A, lower it.

What happens to blank lines or pure whitespace between paragraphs in my TXT?

Blank lines are treated as cue boundaries in timecoded mode, and as paragraph-collapse hints in plain-text mode (consecutive blank lines collapse to one). The converter will not emit an empty SBV cue — every output cue has at least one character of caption text. If you have intentional silences where nothing should display on screen, the SBV output will simply have no cue during those seconds; players handle that gracefully by showing nothing.

Related Convert tools
TXT ConverterConvert Txt To SrtConvert Txt To VttConvert Txt To AssConvert Txt To SsaConvert Srt To SbvConvert Vtt To SbvConvert Ass To Sbv

Image Tools

Image CompressorCompress JPEGCompress PNGCompress GIFCompress WebPImage ConverterJPG ConverterImage Resizer

Video Tools

Video CompressorCompress MP4MP4 to GIFVideo to GIFVideo ConverterMP4 ConverterVideo Cutter

Audio Tools

Audio CompressorCompress MP3Compress WAVAudio ConverterMP3 ConverterFLAC to MP3Audio Cutter

Document Tools

Compress PDFMerge Images to PDFSplit PDFPDF to JPGUnzip FilesRAR Extractor

Converters

Time Zone ConverterMeeting PlannerIST to ESTTime Zone AbbreviationsUnit ConverterLength ConverterFlow Rate Converter
© 2026 XConvert.com. All Rights Reserved.
About UsPrivacy PolicyTerms of ServiceContactHelp Us Grow