Transcript and subtitle formats explained

Start from the destination, not the format

The fastest way to choose an export format is to ignore the formats entirely and ask where the text is going next. If it is going into a video player, an editing timeline, or a web page as captions, you need a timed format: SRT or VTT. If it is going to be read, searched, quoted, edited or filed, you need a document format: TXT or DOCX. Everything else in this guide is refinement of that one rule.

The reason the split exists is timing data. A subtitle file is not really a transcript; it is a sequence of short text fragments, called cues, each stamped with a start time and an end time. A video player reads those stamps and swaps the fragments in and out as playback advances. A document format throws that machinery away and keeps only the words, in reading order, as continuous prose. Neither is 'better', they encode different information for different consumers.

It is also worth knowing that this is not a one-way door. A transcription service that offers multiple formats is generating them from the same underlying transcript, so you can usually download several exports of the same file. FastScribe works this way: one upload produces one transcript, and TXT, SRT and VTT are all direct exports of it, with DOCX available on the Pro plan. If you are genuinely unsure, taking both a TXT and an SRT costs you nothing but a second download.

TXT: the plain-text workhorse

A TXT file is the simplest possible container for a transcript: just the words, encoded as plain text, with no timestamps, no styling, no metadata and no structure beyond line breaks. That poverty is exactly its strength. Every operating system, every text editor, every search tool, every scripting language and every content management system can open and process a TXT file without conversion. It is the closest thing digital text has to a universal format.

Choose TXT when the transcript's job is to be read or reused as raw material. Searching an interview for the moment a topic came up, pasting quotes into your own draft, feeding the text into your own analysis or note-taking system, or simply archiving what was said, all of these want clean, unadorned prose. TXT files are also tiny; an hour of speech typically compresses to a few dozen kilobytes, so you can keep years of transcripts in less space than one photo.

The trade-offs mirror the strengths. TXT carries no formatting, so you cannot preserve bold headings, and it carries no timing, so you cannot recover 'when was this said' after export. If you anticipate needing to jump back to specific moments in the recording, keep a timed export (SRT or VTT) alongside the TXT rather than trying to reconstruct timing later. And if the transcript needs to circulate as a polished, editable document with headings and comments, that is the DOCX use case, covered below.

Want to try it now? Upload a file to FastScribe. Your first one is free, no signup.

SRT: the de facto standard for subtitles

SRT (SubRip Text) is the oldest and most widely supported subtitle format still in everyday use. Inside, an SRT file is surprisingly readable: a numbered list of cues, each with a timestamp line in the form 00:01:23,450 --> 00:01:26,100, followed by one or two lines of text, then a blank line. Note the comma before the milliseconds, that small detail is the classic tell that distinguishes SRT from VTT, and it matters to strict parsers.

SRT's superpower is compatibility. Desktop video players, video editing suites, and the upload dialogs of essentially every major video platform accept SRT sidecar files. If someone asks you for 'a subtitle file' with no further detail, SRT is the safe answer. It is also the format most translation and localization workflows expect as input, because the cue structure gives translators exact segments to work within.

Its limitations come from its age. Baseline SRT has no official support for positioning, colors or fonts, the player decides how cues look. A cue that runs too long or holds too many characters will render as a wall of text on screen, which is a caption-editing concern rather than a format flaw, but SRT gives you no styling tools to soften it. When you need styled, positioned, web-native captions, that is precisely the gap VTT was designed to fill.

VTT: subtitles built for the web

WebVTT (Web Video Text Tracks), usually seen as a .vtt file, is the W3C's modernization of the SRT idea, created for the HTML5 video element. Structurally it looks like a close cousin of SRT: cues, arrows, text. The visible differences are a mandatory WEBVTT header on the first line, a period instead of a comma before milliseconds (00:01:23.450), and optional extras SRT never had, cue positioning, alignment settings, per-cue styling hooks, and comment blocks.

Choose VTT whenever the captions will be consumed by a browser. If you are embedding video on your own site with a standard track element, the specification calls for WebVTT, and native browser captioning simply will not load an SRT file there. Many web-based video platforms and players also prefer or require VTT for their caption tracks. For accessibility work on the web, making embedded media usable for deaf and hard-of-hearing visitors, VTT is the format the tooling assumes.

The practical rule of thumb: SRT for desktop players, editing software and platform upload forms; VTT for anything rendered by a browser. Because the two formats are so close, conversion between them is nearly lossless in the common case, but 'nearly' can still bite, a comma left in a VTT timestamp or a missing WEBVTT header are the classic causes of captions silently failing to appear. Exporting the correct format directly, rather than hand-converting, avoids that whole class of bug.

DOCX: when the transcript needs to be a document

DOCX is the standard word-processing format, and as a transcript export it serves a different master than the other three: human collaboration. Where TXT gives you raw text, a DOCX transcript opens in familiar word processors ready for the document workflows organizations actually run on, styled headings, comments in the margin, tracked changes, and clean printing or PDF conversion.

This matters most when the transcript is a deliverable rather than raw material. Sending an interview transcript to the interviewee for review, circulating meeting notes for correction, or filing a formatted record of a recorded session are all cases where handing someone a bare TXT file creates friction and a DOCX does not. Reviewers can flag mishears with comments, propose fixes with tracked changes, and return a document whose edit history is visible.

On FastScribe, DOCX export is a Pro feature; TXT, SRT and VTT are available to everyone. One boundary worth stating plainly: a DOCX export is still the transcript, the same words, in a richer container. FastScribe does not write summaries, show notes or articles from your recording; if you want the transcript reshaped into some other piece of writing, that remains your work (or your word processor's), starting from the exported text.

Common scenarios, resolved

Captioning a video for a social or video platform: export SRT and upload it alongside your video in the platform's caption settings. Embedding video on your own website: export VTT and reference it from the page's track element. Doing both with the same recording is normal, download both files from the same transcript rather than converting one into the other by hand.

Studying or quoting from a lecture, interview or podcast episode: export TXT, which is instantly searchable and paste-friendly. If you expect to jump back to specific moments in the audio, also grab the SRT or VTT, its timestamps double as a crude index into the recording even if you never use it as a subtitle file. Sending a transcript to a client or colleague for review: export DOCX so they can comment and track changes without asking what to open it with.

Two logistics notes that trip people up. First, transcription tools like FastScribe work from uploaded files: if the source is a video that lives online, download the media file to your machine first, then upload that file. There is no pasting a link. Second, mind size and length limits when choosing what to upload. On FastScribe, your first file is free with no signup up to 50 MB and 10 minutes; a free account raises the size limit to 100 MB; and Pro accepts files up to 2 GB and 5 hours, with batch uploads if you have a backlog. For long recordings, uploading an audio-only version of a video is a simple way to stay comfortably under size limits, and the transcript is identical.

Where FastScribe fits

You have three broad ways to get a transcript, and the right one depends on your volume, budget and stakes. Doing it yourself, playing the audio and typing, or running an open-source speech model on your own hardware, costs nothing but time and technical effort, and time is the catch: manual transcription runs several times the length of the recording, and self-hosting a model means owning the setup. Human transcription services sit at the other end: people listening and typing produce the most reliable results for difficult audio, at prices and turnaround times to match. Automated services like FastScribe sit in the middle: fast, inexpensive, and good enough for most everyday material, though, like all automated transcription, imperfect, especially with heavy crosstalk or poor recordings, so plan to proofread anything high-stakes. FastScribe specifically runs our own transcription engine on our own servers; your audio is deleted the moment your transcript is ready, and only the text is kept. You can try it on your first file free with no signup (up to 50 MB and 10 minutes), a free account raises the cap to 100 MB, and Pro is $12/month for files up to 2 GB and 5 hours, DOCX export, batch uploads, a priority queue, history kept forever, and unlimited files under fair use. If your recordings are rare and difficult, a human service may serve you better; if you enjoy tinkering and have the hardware, DIY is genuinely free. For steady, ordinary transcription work, automated is usually the sensible middle.