SRT to Text: Getting a Clean Transcript Out of Subtitles

The easy half: numbers, timings, blank lines

A SubRip file is four things repeated: a counter, a timings line, one or more lines of text, and a blank line to close the block. Three of those four are scaffolding. Strip them and you have a transcript, which is why every subtitle-to-text converter in existence starts here and why they all succeed at it. This one reads each block, skips forward until it finds a line containing the arrow, and keeps everything after it up to the blank line. The counter is discarded whether or not it is in sequence, so a file with duplicate or out-of-order numbers converts fine.

One consequence worth knowing: a cue with no text at all still counts as a cue. Some encoders emit an empty block to force a caption off screen; the converter finds its timings line, keeps the nothing that follows, and the transcript opens with a pair of blank lines before the first real sentence. Harmless, but it looks like a bug in your export rather than a quirk of your source, so it is worth recognising.

The hard half: everything the converter leaves in

Subtitle text is not plain text. The original SubRip program supported a small set of formatting derived from HTML — bold, italic, underline and colour — and those tags travel with the file. Fansubs and rips add more: {\an8} to move a caption to the top of the frame when it would collide with burned-in text, and square-bracketed sound descriptions like [SEAGULLS CRYING] or [MUSIC] that belong to subtitles for the deaf and hard of hearing. Two speakers in one cue are conventionally marked with a leading hyphen and space on each line. None of that is removed here, and none of it should be removed without a decision from you: whether a transcript keeps its sound descriptions depends entirely on what the transcript is for.

WebVTT brings its own vocabulary, and the converter's treatment of it splits cleanly in two. The structure around the cues is handled: the WEBVTT header line, NOTE comment blocks, STYLE blocks carrying CSS, REGION blocks defining scroll areas, the optional identifier on the line above the timings, and the cue settings list that can follow the arrow — alignment, position, line, region — are all removed, because they never sit inside the cue payload. The markup inside the payload is not handled at all. A voice span, which the specification defines as a start tag v with an annotation naming the speaker, arrives in your transcript as the literal text <v Roger Bingham>. Class spans arrive as <c.yellow>…</c>. Word-level highlighting arrives as bare timestamps like <00:00:07.500> sitting in the middle of a sentence.

Cleaning that up is a find-and-replace job and takes a minute, but do it in the right order. Remove the paired tags first, since deleting the angle brackets alone would leave orphaned attribute text behind. Then decide about the square brackets — keep them for an accessibility transcript, drop them for a translation source. Then decide about the dashes, which carry real information in a two-speaker cue and are pure noise in a single-speaker one. Only after that is it worth reading for sense.

One sentence, two cues: the join no tool can make for you

Subtitles are broken where the screen runs out, not where the sentence does. A single clause routinely spans two cues, and in the transcript that shows up as two lines that read like fragments. The converter offers a merge option, and it is worth being precise about what it merges: the checkbox joins the lines within one cue, so a two-line caption becomes one line. It does not, and cannot, join across cues. Tested on a file whose first cue reads "The thing about the harbour" and whose second reads "is that it never really froze", both modes return two separate lines.

This is not a shortcoming so much as a limit of the input. Nothing in a SubRip file marks where a sentence ends; the only signal available is the punctuation and capitalisation in the text itself, and both are unreliable across languages. The heuristic that works well enough by hand is simple: join a cue to the previous one when the previous one does not end in a full stop, question mark, exclamation mark or closing quotation mark, and when the next one does not begin with a capital letter or a dialogue dash. Applied by a machine that rule mangles German nouns, abbreviations and ellipses; applied by a reader who knows the language it takes a few minutes on a feature-length transcript.

The other recurring mess comes from live captioning. Broadcast captions often roll: a line appears at the bottom, then moves up as the next arrives, and the encoder writes both states as separate cues, so the same sentence appears two or three times in a row in the file. The converter does not de-duplicate — it has no reason to, since a genuinely repeated line of dialogue is also possible — so a transcript from a live broadcast can come out roughly twice the length it should be. Sorting that out is a read-through, and it is the single strongest argument for asking whoever supplies the file for the pop-on version rather than the roll-up one.

SRT or VTT: the same converter twice

There are two converters on this site, one for SubRip and one for WebVTT, and in practice they behave identically. Both read blocks, both skip anything without a timings line, both drop NOTE and STYLE blocks, both accept a comma or a full stop before the milliseconds, and both accept a timestamp with or without the hours field. The only formal difference is that the WebVTT one recognises and skips the WEBVTT header block by name — and the SubRip one drops that block anyway, because a header block contains no timings line and therefore never becomes a cue. Tested side by side on the same WebVTT file, the two produce byte-identical output.

That is convenient rather than sloppy: it means you can paste either format into either page and get the same transcript, which is what you wanted. It also means neither page will tell you that your file is malformed. If the arrow is missing or misspelt on a timings line, that whole block silently disappears from the output rather than raising an error, and the only symptom is a cue count lower than you expected. The count is shown under the input box; compare it against the last number in your file before you trust the result.

Frequently asked questions

Does it strip italic tags, speaker dashes and [MUSIC] labels?

No. It removes the cue number and the timings line, and passes the rest through exactly as written. Tested on a file containing every common case, the output still holds <i>…</i>, <b>…</b>, <font color="#ffff00">…</font>, the ASS-style position override {\an8}, the sound description [SEAGULLS CRYING], the two-speaker dashes at the start of each line, and — in WebVTT input — the voice span <v Roger Bingham>, class spans like <c.yellow>…</c> and inline timestamps like <00:00:07.500>. That is a defensible design, because whether a transcript should keep its sound descriptions depends on what the transcript is for: an accessibility record wants them, a translation source does not. But it means the conversion is one step of two. Budget a find-and-replace pass afterwards, and remove complete tag pairs rather than the angle brackets alone, or you will be left with orphaned attribute text such as color="#ffff00" sitting in your prose.

A sentence runs across two cues. How do I get it onto one line?

Not with the merge checkbox — that joins the lines inside one cue, not two cues together, and the difference is easy to misread from the label. Verified on a file where cue 1 ends mid-clause and cue 2 continues it: both the block mode and the merged mode return two separate lines. The join has to be yours, because nothing in the file marks it. The rule that works is negative on both sides: join a cue to the one before it when the previous cue does not end in a full stop, question mark, exclamation mark, colon or closing quotation mark, and when the current cue does not start with a capital letter or a dialogue dash. Run it as a manual read-through rather than a script — abbreviations, ellipses and, in German, capitalised nouns break it often enough that an automated pass costs more to repair than it saves.

What is the difference between the SRT and the VTT converter?

In observable behaviour, none. They are the same routine with one flag, and the flag only makes the WebVTT version recognise the WEBVTT header block by name — which the SubRip version discards anyway, because that block has no timings line and therefore never becomes a cue. Both drop NOTE and STYLE blocks, both accept a comma or a full stop before the milliseconds, both accept a timestamp with or without the hours field, and both ignore anything after the arrow on a timings line. Fed the same WebVTT file, the two pages return identical text. Use whichever page matches the file you have, for your own sanity, but do not expect the VTT page to clean up voice spans or the SRT page to reject a .vtt: neither happens. The one thing to watch on either page is the cue count under the input box. A malformed timings line makes its whole block disappear without an error, and a count lower than the last number in your file is the only clue.

Why does my transcript repeat the same line two or three times?

Because the source is roll-up captioning. In live broadcast, a caption line appears at the bottom of a two- or three-line window and then scrolls up as the next arrives, and the encoder records each state of the window as its own cue. The same sentence therefore appears in consecutive cues, sometimes three times, and the file is a faithful record of what was on screen at each moment rather than of what was said. The converter does not de-duplicate, and it should not guess: a line of dialogue genuinely repeated for effect looks exactly the same in the file. Removing the repeats is a read-through — sorting the lines to find them destroys the order, so do it in sequence. If you can influence the source, ask for pop-on captions instead: each sentence is written once, and the transcript comes out clean.

I want the text but I also want the timings. What should I use?

Not this converter, which removes the timings by design and gives you no way to keep them. Use the SRT to CSV converter instead: it writes one row per cue with an index, a start, an end and the text, so the timings sit in their own columns and the text is still readable and searchable. That form is also what you want if the transcript is going to be edited or translated by someone else, because it keeps every line tied to the moment it belongs to and can be turned back into a subtitle file afterwards. Plain text is the right output when the destination is prose — a summary, a search index, a document — and the wrong one whenever anybody downstream will need to know when something was said.