Text to SRT: from a paragraph to a subtitle file
You have a script and you need a .srt. Here is what an SRT file actually contains, the three ways people produce one, and why the timings are the only part that is hard.
“Text to SRT” sounds like a format conversion, and it is not one. An SRT file is not text with a different extension — it is text plus timings, and the timings have to come from somewhere.
That is the whole problem. Everything else is punctuation and line breaks.
What is actually inside an SRT file
Plain text, UTF-8, with a repeating four-part block:
1
00:00:00,100 --> 00:00:03,712
If you can hear this sentence, the protocol works.
2
00:00:03,900 --> 00:00:06,240
The second cue looks exactly the same.A sequence number, a time range, one or more lines of text, then a blank line. That is the entire specification worth knowing.
Two details bite people:
- The decimal separator is a comma, not a period.
00:00:01,240. A period there is a WebVTT timestamp, and an SRT parser will reject it. - Hours are not optional.
00:at the front even for a five-second clip.
Three ways to get the timings
You can type them by hand, which is accurate and unbearable past about a minute of audio — it’s what subtitle editors exist for, and if you’re working from existing audio it’s still sometimes the right answer. Or you can transcribe existing audio: speech recognition gives you both the words and roughly when they were said, the words being a guess you’ll need to correct but the timings anchored to real audio.
The interesting case is the third: synthesising the audio from your text. You already have the exact words, so nothing needs recognising — the engine speaking them can report precisely when each word was spoken, which means the timings aren’t inferred at all.
That last route is the only one where the words are guaranteed correct and the timings are measured rather than estimated — you brought the script, and the engine reports what it did with it.
The trap in the third route
It only works if the tool asks the engine for word timings. Many do not. They synthesise the audio, look at its total length, and divide that across your text proportionally to character count.
It produces a file. The file is wrong in a specific way: it drifts. Speech is not evenly paced, so every pause the estimate does not know about pushes the rest of the file further out of alignment. Ten seconds in, it is close. Two minutes in, it is visibly late.
→ How word-level subtitle timing actually works
Line breaks are part of the job
An SRT cue can hold several lines, and where you break them changes how readable the file is. The conventions worth following:
- Two lines per cue, maximum. Three is a wall of text on a phone.
- Break at a grammatical boundary — before a conjunction, after a clause. Never split an article from its noun, or a preposition from its object.
- Balance the lines roughly, rather than filling the first and leaving two words on the second.
→ Subtitle timing rules: cue length, reading speed and line breaks
Converting SRT to VTT
If you end up needing WebVTT instead, the conversion is nearly trivial: add a
WEBVTT line at the top, drop the sequence numbers, and change every timestamp
comma to a period. That is genuinely all of it for a plain file.
It is still better to export both from the start. They cost a few kilobytes, and re-synthesising to get the other one gives you slightly different audio.
→ SRT or VTT: which subtitle file do you actually need?