TXT vs SRT vs VTT: Which Transcript Format to Use

Format comparison at a glance

TXT: the format for content, not captions

Plain text output is the right choice whenever you are working with the words, not the timing. Blog posts, email newsletters, social media copy, study notes, research quotes — all of these need clean prose. TXT delivers that: continuous paragraphs, no timestamp interruptions, no sequence numbers breaking the flow. The WebVTT specification explains how the structured format alternatives work if you're curious about what TXT strips out.

The one thing TXT cannot do is go back to timed captions. Timing data is permanently absent. There is no tool that accurately regenerates timestamps from plain text alone. If you might need the timed version later, download SRT now and convert to TXT yourself by opening the file and deleting the timestamp lines. That takes two minutes. Re-generating timestamps from scratch takes much longer.

SRT: what the file actually looks like

SRT is simple. Each caption block has three components: a sequence number, a timestamp line, and the caption text. Blocks are separated by a blank line.

1
00:00:00,000 --> 00:00:03,400
This is the first caption block.

2
00:00:03,500 --> 00:00:07,200
This is the second caption block.
It can span two lines.

3
00:00:07,300 --> 00:00:10,100
And so on.

The timestamp separator is a comma, not a period. That single character difference causes Facebook to reject files when they contain 00:00:01.500 instead of 00:00:01,500. The error message Facebook returns does not usually identify the cause.

Facebook also requires the language code in the filename. For US English:video.en_US.srt. The full upload process is covered in the subtitle upload guide.

VTT: the web standard

WebVTT is the format browsers use natively. An HTML5 <video> element reads a VTT file via the <track> element and renders captions without any JavaScript. This makes VTT the correct format for embedding video on a website where you control the player.

VTT and SRT contain almost identical information. The practical differences: VTT has a WEBVTT header on line one; timestamps use periods (00:00:01.500) instead of commas; and VTT supports additional metadata like region positioning and CSS styling that SRT does not. Facebook and LinkedIn reject VTT because their upload parsers expect SRT specifically. YouTube and Vimeo accept both. I've had SRT rejections on Facebook catch me out more than once — the period-vs-comma difference in timestamps is genuinely easy to miss when converting between formats.

The counterintuitive fact about VTT: most transcription workflows do not need it. If you are publishing video on social platforms, SRT covers everything. VTT only becomes relevant when you are self-hosting video on a website and need the browser to handle captions natively without a platform intermediary.

Converting between formats

VTT to SRT: open the file, delete the first line (WEBVTT) and the blank line after it, then find-and-replace all period timestamp separators with commas. Save as .srt. That takes under two minutes for any file length.

SRT to VTT: add WEBVTT as the first line with a blank line after it, then replace comma separators with periods in timestamps. Save as .vtt.

Neither conversion is lossy. The only lossy conversion is TXT export — once timing data is gone, it cannot be recovered without re-processing the original audio. See the transcript editing guide for best practices on reviewing and correcting transcript output before exporting in any format.

When the right format depends on your workflow, not the platform

Several use cases genuinely require both formats from the same transcript. A podcast episode might need TXT for the show notes, SRT for the YouTube caption upload, and another TXT version for the newsletter. The key insight: download all formats you will need at the time of transcription, not after. Once you have closed the result and discarded the session, you typically need to re-run the transcription to get a different format — the TXT does not contain the timing data needed to regenerate SRT.

For research workflows where the transcript will go into a text analysis tool, TXT is always correct. Analysis tools — whether spreadsheet-based coding, NLP processing, or keyword analysis — work with plain text. SRT sequence numbers and timestamp lines pollute the text data and produce false results in word frequency analysis and keyword searches. Strip the SRT metadata before any text analysis, or export TXT from the start.

Transcript formats and SEO: what actually matters

Google indexes text in HTML, not text in caption files. A TXT transcript converted to HTML paragraphs on a webpage is fully indexed. An SRT file linked for download may be partially indexed by Googlebot — it reads some file types linked from pages — but the indexing is less consistent and less complete than HTML text.

The practical implication: if you want a transcript to drive organic search traffic, publish it as HTML content on a page, not just as a downloadable file. A blog post with the transcript text as readable paragraphs — with the video embedded — is the most SEO-friendly format. The transcript adds keyword-rich content that the video alone can't contribute to search engines, since Google can't index spoken audio.

Format portability is a separate consideration from SEO. TXT is readable in any environment: a phone, a text editor from 1995, a terminal window. SRT requires a player or editor that understands the format. VTT requires a browser-compatible environment. For long-term archiving, TXT is the most durable choice. For operational captioning, SRT or VTT serves the immediate purpose but is less durable as a standalone archival record. Keep a TXT copy alongside caption files for long-term storage.

The practical recommendation for any transcription session: download both TXT and SRT before closing the session, even if only one format is immediately needed. The SRT takes three seconds to download. Re-running a transcription later to retrieve timestamps because the session was closed with only TXT saved wastes the entire original processing time. Both formats from the same session is the minimum sensible default.