Turn a TXT subtitle file into a VTT (WebVTT) subtitle file in seconds—right in your browser.
.txt files and each becomes its own .vtt. Files are read in your browser; nothing leaves the device.hh:mm:ss.fff format the W3C WebVTT spec requires (period separator before milliseconds, not the comma SRT uses). The required WEBVTT header is written automatically on line 1.Anna:, decide whether you want those treated as cue text or stripped — edit the source TXT and re-upload if needed. Captions read most comfortably at roughly 160-180 words per minute (about 0.3 seconds per word), the speed the BBC's subtitle guidelines recommend for accessibility, so very long single lines may need to be split first..vtt file, the encoding required by both the W3C spec and HTML5 video players. Download individually or grab a ZIP for the whole batch — no sign-up, no watermark.A .txt transcript is just human-readable prose — useful for reading, useless to a <track> element. WebVTT (Web Video Text Tracks) is the W3C-standardised caption format that HTML5 video understands natively, and it has been widely supported in every major browser since July 2015. Wrapping a transcript in WebVTT structure unlocks captions on the web, on streaming platforms, and in accessibility tooling. Common reasons to make the conversion:
<video> with a child <track kind="captions" srclang="en" src="captions.vtt"> only accepts WebVTT (or its superset, TTML). Chrome, Firefox, Edge, and Safari render .vtt natively; plain .txt is ignored..vtt as a first-class input. Most cloud encoders refuse .txt..txt lyric sheet exported from a DAW or songwriting app becomes karaoke-style on-screen captions once timed and wrapped in VTT cues. The same source can drive both web video captions and music-player lyric overlays..txt back into VTT preserves cue boundaries for the engineer to fine-tune in tools like Aegisub or Subtitle Edit.<v Speaker Name> voice tags, STYLE blocks with CSS ::cue selectors, positioning (line, position, align, size), and chapter markers. SRT supports none of those natively..txt transcript alone doesn't qualify; the captions must be time-synchronised, which is exactly what the VTT structure encodes.| Property | TXT | VTT (WebVTT) |
|---|---|---|
| Standard | None — just plain text | W3C WebVTT 1.0 (Candidate Recommendation Draft) |
| Required header | None | WEBVTT on line 1 |
| Timing | None | Per-cue hh:mm:ss.fff --> hh:mm:ss.fff |
| Cue identifier | n/a | Optional line above each cue |
| Speaker labels | Convention only (e.g. Anna:) |
<v Anna>Hello.</v> voice tag |
| Styling | None | STYLE blocks + ::cue CSS, <b>, <i>, <u>, <c.classname> |
| Positioning | n/a | line, position, align, size cue settings |
| Encoding | Any (often Windows-1252) | UTF-8 required |
| MIME type | text/plain |
text/vtt |
HTML5 <track> support |
No | Yes — native |
| Best for | Reading, archive, search | Captions, subtitles, chapters on web video |
| Part | Example | Notes |
|---|---|---|
| Header | WEBVTT |
Required on line 1; optional description after a space |
| Blank line | (empty) | Separates header from first cue |
| Cue ID (optional) | intro or 1 |
Any string without --> or newlines |
| Timecode | 00:00:01.000 --> 00:00:03.500 |
Period (not comma) before ms; hours optional under 1 h |
| Cue text | Welcome to the show. |
One or more lines; ends at blank line |
| Voice tag | <v Anna>Hello there.</v> |
Optional speaker identification |
| Cue settings | line:90% position:50% align:center |
Appended after the timecode on the same line |
| STYLE block | STYLE\n::cue { color: yellow; } |
Optional; must appear before any cue |
A minimal valid VTT therefore looks like:
WEBVTT
00:00:01.000 --> 00:00:03.500
Welcome to the show.
00:00:03.600 --> 00:00:06.000
<v Anna>I'm Anna, and this is episode one.</v>
If you also need the reverse direction or a different target, see Word Counter for measuring how long captions will run, and Text Case Converter for normalising shouted-caps source transcripts before conversion.
Plain text has no timing information, so the converter assigns sequential cues at a conservative reading rate of roughly 0.3 seconds per word — close to the widely-cited BBC subtitle guideline of 160-180 words per minute. Each non-empty line becomes one cue, and cues are placed back-to-back with no gaps. Treat the output as a starting point: import into Aegisub, Subtitle Edit, or any VTT editor and nudge timings to match the actual audio. Without the source audio there is no way for any tool to produce frame-accurate timing automatically.
It's a deliberate spec choice. SRT, which predates HTML5, follows European decimal convention (00:00:01,500). WebVTT, written for HTML5 video and modeled partly on CSS conventions, uses the dot (00:00:01.500). A .vtt file with comma separators is invalid and most browsers will silently fail to render the track. The converter writes periods by default — you don't need to do anything.
Yes, partially. If your source TXT marks speakers with a Name: prefix at the start of a line (e.g. Anna: Hello there.), the converter recognises that pattern and emits <v Anna>Hello there.</v> in the cue. If the source uses brackets like [ANNA] or scriptwriter-style centered names, edit those into Name: form before uploading. Voice tags are a VTT-only feature — converting back to SRT later will strip them, since SRT has no equivalent.
Append a STYLE block at the top of the VTT (after the WEBVTT header, before the first cue) with ::cue { color: yellow; } or scoped to a class like ::cue(.warning) { color: red; }. For positioning, edit each cue's timecode line to include settings such as line:0 position:50% align:center (top, centered) or line:90% (near the bottom). The converter does not write these by default — they're optional CSS-style enhancements you add after the conversion in any text editor.
YouTube accepts .vtt uploads but typically prefers SRT; both work. Vimeo, Brightcove, JW Player, Kaltura, and Wistia accept VTT directly. Facebook and LinkedIn upload pipelines historically prefer SRT — if you're targeting those, convert your VTT to SRT after editing. Twitch, OBS, and Streamlabs use VTT for stored VOD captions. When in doubt, keep the VTT master and export SRT copies for picky platforms.
UTF-8, as required by the W3C WebVTT specification. Plain .txt files from Windows Notepad sometimes save as ANSI / Windows-1252, which mangles accented characters (é, ü, ñ), em-dashes, smart quotes, and any non-Latin script (Japanese, Arabic, Cyrillic) when reinterpreted as UTF-8. The converter reads the source bytes and re-encodes as UTF-8 with a BOM omitted (browsers prefer no BOM). If your output shows é instead of é, re-save the source TXT as UTF-8 before re-converting.
Yes — the converter treats each line break in the source as a cue boundary. A single-paragraph transcript becomes one cue with the full duration, which renders unreadably. Split the text into logical lines first (one sentence per line is a safe default, or break at natural pauses every 6-10 words). The BBC's two-line maximum recommendation is a good ceiling — anything longer crowds the screen and exceeds typical reading speed.
Yes — overlapping timecodes are valid WebVTT. If two cues span the same timeframe (one for a speaker, one for an on-screen description), the player renders both. Use line:0 for one and line:90% for the other to keep them separated vertically. Plain TXT has no concept of overlap, so the converter never emits overlapping cues automatically — you add them after by editing the output, or by structuring the source TXT with explicit cue boundaries you fine-tune later.
Both wrap timed lines of text. The differences that matter day-to-day: VTT requires the WEBVTT header and UTF-8; SRT doesn't. VTT uses periods before milliseconds; SRT uses commas. VTT supports voice tags, CSS styling, positioning, and chapter markers; SRT supports none of those officially. VTT is the only format HTML5 <track> accepts; SRT is the de-facto standard everywhere else (YouTube, Premiere, Final Cut, DaVinci Resolve, Aegisub). If you're targeting web video, pick VTT. If you're targeting an editor or social platform, SRT is safer.