Turn a plain TXT subtitle file into a standard SRT subtitle file in seconds—right in your browser.
.txt script, 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 an entire folder of transcripts can be processed at once.HH:MM:SS markers). For plain text, the default duration per cue is 2.5 seconds with no gap — adjust if your script reads faster or slower. For timecoded text, the parser accepts mixed separators (. or , for milliseconds, : for seconds) and normalises every cue to strict SRT grammar.HH:MM:SS,mmm --> HH:MM:SS,mmm with the comma-millisecond separator SRT requires, and saves the file as yourscript.srt. No sign-up, no watermark, no email.TXT is a plain-text transcript — words on a page with no concept of time. SRT (SubRip Subtitle), invented in 2000 for the SubRip DVD-ripping tool, became the de-facto subtitle interchange format because the spec is trivially small: a sequential number, a HH:MM:SS,mmm --> HH:MM:SS,mmm timecode line, the caption text, and a blank line between cues. Every major video editor, streaming platform, and media player on the planet parses SRT. The conversion adds timecodes to a transcript so it can ride along with video. Common reasons:
.txt script is useless to them; an .srt lands on the timeline with cue boundaries intact.movie.srt next to movie.mkv in the same folder and Samsung Tizen, LG webOS, Roku, Plex, Jellyfin, and Kodi pick it up automatically. A .txt in the same place is ignored.| Property | TXT (transcript) | SRT (SubRip) |
|---|---|---|
| Origin | Generic plain text, pre-dates personal computing | SubRip ripping tool, 2000 |
| Timecodes | None (unless ad-hoc) | Required: HH:MM:SS,mmm --> HH:MM:SS,mmm |
| Millisecond separator | N/A | Comma , only (never period) |
| Cue numbering | None | Required, sequential integers starting at 1 |
| Block separator | Newline | Blank line between cues |
| Style markup | None | <b> <i> <u> <font color> player-dependent |
| Encoding | Anything (often ANSI/Windows-1252) | UTF-8 strongly recommended; UTF-8 mandated by YouTube |
| MIME type | text/plain |
application/x-subrip (informal) |
| Native players | Text editors, word processors | VLC, MPV, MX Player, smart TVs, every NLE |
| Native platforms | Note apps, docs, transcript downloads | YouTube, Vimeo, TikTok, Netflix (personal use), Plex |
| Typical use | Reading, indexing, search, archive | Captions, subtitles, sidecar files |
| Your TXT looks like… | Pick this mode | What the converter does |
|---|---|---|
| One caption per line, no timestamps | Plain Text (auto-timing) | Assigns a default duration (default 2.5s) to each line, lays cues end-to-end with no gap |
00:01:23 Caption text (one timestamp per line, start only) |
Timecoded — start-only | Uses each timestamp as the start of a cue, ends each cue when the next one begins (or +3s for the last line) |
00:01:23 - 00:01:26 Caption text |
Timecoded — start and end | Parses both timestamps and writes them directly to the SRT cue |
| Mixed dot/comma milliseconds | Any timecoded mode | Normalises .456 and ,456 and :456 all to ,456 as SRT requires |
Speaker labels like JOHN: Hello there |
Plain or timecoded | Speaker labels are preserved verbatim inside the caption text (most players show them as part of the line) |
A TXT transcript is just words on a page — there's no synchronisation with the video. An SRT file adds three things on top of those words: a sequential cue number, a start/end timestamp in HH:MM:SS,mmm --> HH:MM:SS,mmm format, and a blank line between cues. Players use the timestamps to display each caption at exactly the right moment. Without timecodes a video player has no way of knowing when "Hello world" should appear on screen.
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 00: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.
That's how the SubRip parser was originally written in 2000, and every downstream player copied the same grammar. WebVTT, designed later by the W3C for HTML5 <track>, chose the period instead. The two formats look nearly identical otherwise, but a single 00:01:23.456 line in an SRT file is enough to make VLC, Premiere, and YouTube treat the whole cue as malformed. If you see "subtitles not displaying" errors, check the millisecond separator first.
Yes. YouTube's supported-formats page lists SubRip (.srt) as a basic caption format and requires plain UTF-8 with no style markup — exactly what the converter outputs by default. Upload via YouTube Studio → your video → Subtitles → Add language → Upload file → "With timing" → select the .srt. Captions appear within a few minutes after processing.
Pick timecoded mode. The parser accepts: HH:MM:SS, MM:SS, H:MM:SS, [00:01:23], 00:01:23,456, 00:01:23.456, and 00:01:23:456 (frame-style). It normalises all of them to SRT's strict HH:MM:SS,mmm syntax. If a line has both a start and end timestamp separated by -, –, →, or -->, both are parsed. If only a start is present, the cue ends when the next cue starts (or 3 seconds after, for the last line).
??? 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 representing those characters are garbled before the converter even 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. The output is always UTF-8 by spec, which is what YouTube, Vimeo, and modern players require.
There's no hard SRT limit, but human readability is the constraint. Industry guidance from BBC subtitle guidelines and Netflix Timed Text Style Guide is roughly 160-180 words per minute reading speed, which works out to a maximum of 42 characters per line, two lines per cue, and 1-6 seconds of display time. The default 2.5-second cue in plain-text mode lands in that range for a typical 1-2 short-sentence line. For dialogue-heavy scripts, raise the per-line duration; for fast Q&A, lower it.
Yes. The converter treats anything on the caption-text line as part of the caption — speaker labels, stage directions in brackets, parenthetical sound cues, all preserved verbatim. Most subtitle players display them as part of the line. If you want each speaker on a separate visual line within the cue, just put them on separate lines in the source TXT before the next blank-line cue separator.
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 SRT cue — every output cue has at least one character of caption text. If you have intentional pauses where nothing should display, leave those gaps in your video and the SRT will simply have no cue during those seconds.
VTT (WebVTT) is the W3C format for HTML5 <track> elements — it uses periods instead of commas before milliseconds and starts with a WEBVTT header line. If you're embedding captions on your own website via the HTML5 <video> element, VTT is the right choice. If you're uploading to YouTube/Vimeo, editing in Premiere or DaVinci, or dropping a sidecar file next to a movie for Plex, pick SRT.