SRT to Text Converter

There's a particular flavor of absurdity in exporting a YouTube transcript and receiving a document where '00:00:04,120 --> 00:00:07,850' interrupts every clause. The words you need are all present. The sentences are intact. And every three seconds, a timing code parachutes in between the subject and the verb, like a court reporter with an unshakable compulsion.

You could clean it by hand. Forty minutes of lecture is roughly 400 caption blocks, each needing two lines deleted and two lines merged — an hour of mechanical labor that gives you nothing but the text you already had. Or you could paste it here, click once, and watch the SRT to Text Converter hand back the same words wearing normal clothes: numbered indexes gone, timestamps gone, caption fragments joined into paragraphs, the actual transcript standing there as if it had never been dressed as a subtitle file at all.

The strange part is how few tools do this well. The subtitle ecosystem is built around creating and displaying captions, not reading them — so the people who just want the words (students, journalists, researchers) end up fighting software designed for something else entirely. This page is the opposite: it does nothing but the reading part, and it does that in one click, locally, for free.

The converter gives you control over the four layers of SRT housekeeping, because different jobs want different amounts of cleanup:

• Sequence numbers — the running caption index (1, 2, 3…) — removed always. They're player bookkeeping, not content.
• Timestamps — every 00:00:04,120 --> 00:00:07,850 line — removed always. This is the headline feature and non-negotiable.
• Line joining — the caption's hard line breaks merged, and consecutive captions stitched into flowing paragraphs. Optional: leave it off and the text keeps the original caption-per-line structure.
• Duplicate merging — repeated words from overlapping cues collapsed into single sentences. Optional, and worth understanding before using, because it fixes a real quirk of how captions get written.
• SDH cleanup — bracketed sound descriptions like [phone buzzing] removed, speaker labels kept or removed at your discretion.
• Timing export — if you want the timestamps back later, an option to output a two-column text file pairing each caption with its start time, which is how researchers quote video precisely.

1. 1

   Paste or drop the SRT

   Paste the raw file contents into the box, or drop the .srt (or .vtt) file onto it. The converter reads it as UTF-8 text, handling both Windows and Unix line endings automatically.

2. 2

   Choose your cleanup level

   Keep it minimal (indexes and timestamps out, structure intact) or go full transcript (lines joined, duplicates merged, sound captions stripped).

3. 3

   Convert and eyeball the result

   The output pane renders instantly. Scroll the top and bottom of a long file — those are where format quirks concentrate: the first block and the last.

4. 4

   Copy or download

   Copy to clipboard for pasting into a doc, or download as .txt. The output is deliberately boring plain text so every editor, CMS, and email client on earth accepts it without ceremony.

You don't need a spec document to use the converter, but knowing the four-part structure explains every option on the page — and makes you the person in the room who can debug a broken subtitle file. A caption block is exactly this:

1
00:00:01,400 --> 00:00:04,120
Okay, so today we're going to talk
about the phosphorus cycle.

2
00:00:04,120 --> 00:00:07,850
And I know last week someone asked
whether phosphorus is renewable,

3
00:00:07,850 --> 00:00:10,000
so let's start there.

• Line one: the sequence number. A plain integer, one per caption, strictly increasing in a well-formed file — and purely optional to the format's function; players ignore it.
• Line two: the timing. Two timestamps in hours:minutes:seconds,milliseconds joined by an arrow (' --> '), marking when the caption appears and disappears. The comma before the milliseconds is the format's most fragile convention.
• Lines three and beyond: the text. One or more lines, usually wrapped to around 40 characters per line for on-screen readability — which is why transcripts straight from SRT look ragged.
• A blank line: the block separator. Two consecutive line breaks mean 'caption ends here.' The file's last block is allowed to omit the trailing blank line, which is the number-one source of off-by-one parsing bugs.

The format descends from SubRip, a Windows ripper that extracted subtitles from video by OCR, and its success made it the lowest common denominator of the subtitle world — every player speaks it, no spec governs it. The web needed something with a formal definition, and the W3C standardized WebVTT for HTML5 video, borrowing SRT's structure wholesale but swapping the comma for a dot in timestamps and adding a WEBVTT header. That heritage matters here because half the 'SRT' files in circulation are actually WebVTT with the extension changed — and a converter that only matches commas quietly produces empty output. This one detects both.

The conversion is a small decision tree, run once per caption block, and it's worth being transparent about because it's where correctness lives. First, the file is normalized: line endings unified (Windows files arrive with carriage returns that would otherwise glue themselves to the ends of text lines), and a leading byte-order mark discarded if present. Then the text splits into blocks at every blank line.

Each block is examined top-down. If the first line is nothing but digits, it's the sequence number and gets dropped. If a line matches the timestamp pattern — two timecodes with an arrow between them, commas or dots both accepted — it's timing metadata and gets dropped. Every remaining line is content. The content lines from one block are joined; whether blocks are then stitched into paragraphs depends on your line-join setting, which uses punctuation at caption boundaries as its sentence signal: a block ending in a period, question mark, or exclamation closes a paragraph, and one ending mid-clause continues it.

The duplicate-merge pass runs last and conservatively. Captioners bridge sentence splits by repeating a few words — cue 2 ends 'asked whether' and cue 3 begins 'whether phosphorus' — and the parser recognizes the overlap when one cue's tail matches the next cue's head, keeping the overlap once. Where the overlap doesn't match exactly, both passages are kept, because wrongly deleting real speech is a worse failure than leaving a repeated word.

The file's own census checks out the same way. Four hundred twelve cues across a 38:14 runtime is one cue every 5.6 seconds; 5,612 words across those 412 cues averages 13.6 words per cue; and 5,612 words over 2,294 seconds is 147 words per minute of speech — a measured, lecture-paced speaker. When your own export's numbers disagree wildly with these ratios — say 60 words per cue — you are looking at auto-generated timings that hug the audio waveform instead of following readable pacing.

The number that surprises people is the last pair: a 38-minute lecture reads in about 22 minutes. Speech runs near 150 words per minute, reading runs near 250 — which is the entire argument for converting lecture captions to text before a revision session, an exam week, or any moment of 'I know he said the thing about the phosphorus, but when.' Searchable, skimmable, quotable: three things a video timeline is not.

For anyone building the pipeline in reverse — video in, transcript out — the standard route is ffmpeg pulling the subtitle track, then this page finishing the job:

# Extract the first embedded subtitle track to SRT
ffmpeg -i lecture.mp4 -map 0:s:0 lecture.srt

# Then paste lecture.srt here for clean text

Before stripping them, the timestamps can answer a question nobody thinks to ask: how fast is this video actually captioned? The measure is characters per second — caption length divided by cue duration — and it has real professional standards. Netflix's timed-text guideline caps adult programs around 20 CPS; broadcast captioners historically work near 15 to 18; anything above the low twenties reads as flash-frames for anyone processing at reading speed.

Run that arithmetic across a whole file and the outliers tell you where comprehension will suffer: auto-generated captions routinely average 25-plus CPS on fast speakers because the timings hug the speech itself rather than allowing reader reaction time. The timing-export option exists partly for this audit — a two-column file of cue times and text is one spreadsheet formula away from a CPS column for every line of the video.

The same numbers also explain a conversion quirk: tightly-paced cues tend to carry sentence fragments that bridge across blocks, because the captioner ran out of time, not words. If your CPS audit shows a fast file, expect the duplicate-merge option to earn its keep — the overlap pattern that option fixes is the signature of timing pressure.

The timestamps look decorative until you do arithmetic with them, and the arithmetic is one formula: milliseconds = ((hours × 60 + minutes) × 60 + seconds) × 1000 + milliseconds. Every conversion below is that line, applied:

The reverse direction runs the divisions in order: hours = ms ÷ 3,600,000, then minutes from the remainder ÷ 60,000, then seconds ÷ 1,000, then what is left is the millisecond field. 7,832,450 milliseconds converts back to 02:10:32,450 — 2 hours, 10 minutes, 32.45 seconds.

Subtraction is where the format gets useful. A cue's duration is simply end minus start: the first sample cue runs 4,120 − 1,400 = 2,720 ms, the second 7,850 − 4,120 = 3,730 ms. And the boundary habit of the sample — each cue's end equaling the next cue's start — is itself data: gap = next start − previous end computes to zero three times in a row, meaning this captioner cut on speech rhythm with no breathing room. A positive gap marks deliberate silence; a negative gap is an overlap, two cues claiming the same screen moment — technically illegal, occasionally intentional, always worth flagging before a file ships.

SRT has no governing spec and a decade of tool authors improvising, so real files arrive full of heresies. These are the ones this converter is specifically armored against — and the ones to check for when some other tool hands you back an empty box:

• CRLF line endings. Windows editors save with carriage-return line-feed pairs, and a parser that splits on bare newlines leaves invisible \r characters glued to every caption's last word. This converter normalizes endings first — it's the difference between 'cycle.' and 'cycle.\r' in your output.
• The UTF-8 BOM. A three-byte marker some editors prepend, which attaches itself to the first sequence number and makes '1' unrecognizable as a digit. Detected and discarded before parsing begins.
• Dots instead of commas. WebVTT-style timestamps (00:00:04.120) in a file wearing an .srt extension — the classic YouTube caption export. Accepted transparently, along with the WEBVTT header line.
• Stray HTML and positioning tags. Italic markup like <i> and positioning codes like {\an8} (borrowed from the SSA/ASS family) ride along in some caption files. Tags are stripped; the words inside survive.
• Missing final blank line. A file that ends immediately after the last caption's text is legal in practice and fatal to parsers that only recognize block boundaries. The final block is flushed explicitly.
• Duplicate bridging cues. As covered above: sentence fragments repeated across consecutive cues, collapsed by the optional merge pass with exact-match verification.
• Speaker labels and SDH brackets. Lecture captions often carry DR. CHEN: prefixes and [slide changes] descriptions. Kept by default (they're meaningful in transcripts), toggleable when they're noise.
• Multi-language files. Subtitle tracks that alternate languages line by line clean fine — the format is text, and text has no opinion about alphabets.

A qualitative study with twelve 45-minute interviews produces roughly 5,760 caption cues and about 81,000 words of raw SRT — 324 pages at reading density, none of it quotable until the format goes away. The pipeline that turns that pile into coded data runs through this converter twice, and it is worth walking once.

1. 1

   Batch-extract the caption tracks

   One ffmpeg line per recording: ffmpeg -i interview07.mp4 -map 0:s:0 interview07.srt pulls the first subtitle track. Embedded auto-captions work as well as professional ones — the cleaning stages do not care who wrote the cues.

2. 2

   Convert each file with the research settings

   Line-join on for flowing paragraphs, duplicate-merge on because auto-captions bridge sentences aggressively, SDH cleanup off — [laughs] and [pause] are data to a qualitative researcher, not noise. Speaker labels stay on for multi-voice interviews.

3. 3

   Import the clean text into the coding software

   Analysis tools tokenize on clean paragraphs, and every stray sequence number or timestamp would have been a junk token in the codebook. Twelve .txt files load where twelve .srt files stammer.

4. 4

   Re-run the timing export for the pull-quotes

   Every quote destined for the write-up needs a locatable source. The two-column timing output pairs each caption with its start time, so a coded passage like 'identity renegotiation, 00:41:12' points reviewers straight at the moment in the recording.

The arithmetic of the payoff: 12 interviews at 45 minutes is nine hours of playback for a full review pass, versus roughly five and a half hours reading the transcripts at 250 words per minute — before counting the searchability, which is where transcripts stop being a convenience and become an instrument. Ctrl-F through 81,000 words finds every utterance of a theme code in milliseconds; a video timeline finds them never.

• Students converting lecture captions into revision notes — the single biggest audience for this kind of tool, every semester, forever.
• Journalists turning interview subtitles into quotable transcript, where a timestamped quote is a formatting error and a clean one is a paragraph.
• Qualitative researchers preparing caption exports for coding software, where every stray index number becomes a token the analysis has to ignore.
• Video editors extracting scripts from their own old projects — the captions you made three years ago are a shot list with dialogue attached.
• Translators using SRT text as source copy: strip to clean text, translate, then re-time — this tool is step one of that pipeline.
• Podcasters who had their episodes auto-captioned and want the text for show notes, newsletter pull-quotes, and searchable archives.
• Accessibility auditors and content teams producing text alternatives at scale, where the caption file is already the transcript wearing the wrong clothes.

The downstream workflow usually continues in text tools: silence-cleaned audio for the time-conscious, PDF text extraction when the source material escaped as a document, and a browser recorder when the next interview hasn't happened yet — captions start life as clean takes.

Subtitles come in more dialects than most people ever meet, and the differences are small enough to bore you and large enough to break parsers. The practical field guide:

The WebVTT column deserves a closing note: it's the W3C-standardized descendant of this whole lineage, formally specified for the web platform where SRT never had a spec at all. If you're building things that display captions in browsers, VTT is the correct citizen; if you're reading them, either one lands here and becomes the same clean text.

Subtitle files are transcripts, and transcripts are sensitive documents — lectures under nondisclosure, interviews with sources, medical content, legal depositions. The converter therefore has no upload step to decline: the file you drop is read by the page you're on, parsed by JavaScript in your browser, and rendered into the output pane on the same screen. It never crosses the network, because there is no network crossing in the design.

There's also a sheer courtesy argument: this is a 40-kilobyte text file and a two-millisecond computation. Uploading it to a queue, waiting for a render, and downloading the result was always a workaround for websites that needed your page views. Text work belongs on your machine, and here it stays.

Transcript work tends to travel with other extraction jobs. The Audio Silence Remover tightens the source recording before captioning; the PDF text extractor handles the documents that arrived as print-shaped files; and the Online Voice Recorder captures the next interview cleanly enough that its captions — and this converter — have an easy time of it. One browser tab at a time, the world becomes text.