Subtitle & Transcript File Formats Explained: SRT, VTT, TXT, JSON, CSV & More

Transcribe a file and you're immediately asked which format you want it in. SRT? VTT? TXT? Something with JSON in the name? The formats are not interchangeable — each one throws away information the others keep, and picking the wrong one means redoing the export or writing a converter.

This is a reference to every format a transcript commonly comes in: what it looks like, what it's for, and how to move between them.

The one-table summary

Format	Timestamps	Styling	Machine-readable	Best for
SRT	Yes (cue-level)	Minimal	Semi	Subtitles/captions, near-universal support
VTT	Yes (cue-level)	Yes (positioning, cues)	Semi	Web video (`<track>`), HTML5 players
TXT	No	No	No	Reading, quoting, pasting into a doc
TSV	Yes (columns)	No	Yes	Spreadsheets, scripts, data pipelines
CSV	Yes (columns)	No	Yes	Excel/Sheets, imports
JSON	Yes (per segment)	No	Yes	Programmatic use, APIs, custom apps
ASS / SSA	Yes	Yes (rich)	Semi	Styled/karaoke subtitles, anime fansubs
SMI (SAMI)	Yes	Yes (HTML/CSS)	Semi	Legacy Windows Media
TTML	Yes	Yes (rich)	Yes (XML)	Broadcast, streaming delivery

The rest of this guide is the detail behind each row.

SRT (SubRip)

The lingua franca of subtitles. Almost every player, editor and platform accepts .srt. A file is a list of numbered cues: an index, a start-and-end timestamp, one or more lines of text, then a blank line.

1
00:00:00,498 --> 00:00:02,827
Hello, and welcome to the show.

2
00:00:02,900 --> 00:00:05,110
Today we're talking about file formats.

Note the comma before the milliseconds (,498) — that's SRT's signature and the thing most hand-written converters get wrong. Styling is limited to basic tags. Use SRT when you want the widest possible compatibility.

Convert into or out of it: VTT to SRT, SRT to text, SRT to Word, SRT to PDF, or retime cues in the SRT editor.

VTT (WebVTT)

The web's native subtitle format, designed for the HTML5 <track> element. It looks like SRT with three differences: a required WEBVTT header, a dot before the milliseconds (not a comma), and support for cue positioning, styling and metadata.

WEBVTT

00:00:00.498 --> 00:00:02.827
Hello, and welcome to the show.

00:00:02.900 --> 00:00:05.110 line:90% align:center
Today we're talking about file formats.

Use VTT when the video plays in a browser or an HTML5 player. If a platform rejects your file, the SRT/VTT mismatch is the usual culprit — swap with SRT to VTT or VTT to text.

TXT (plain text)

The whole transcript as prose, no timestamps, no structure. This is what you want for reading, quoting in a document, pasting into a blog post, or feeding to another tool that just needs the words. It's the most human-friendly export and the least useful for anything that needs timing.

TSV and CSV

Tabular transcripts: one row per segment, with start time, end time and text as columns (TSV separates them with tabs, CSV with commas).

start	end	speaker	text
0	2827	S1	Hello, and welcome to the show.
2900	5110	S1	Today we're talking about file formats.

Open either in Excel or Google Sheets, or read it line by line in a script. TSV is the safer of the two for transcripts, because spoken text is full of commas that break naive CSV parsers; tabs almost never appear inside the text itself. Reach for these when you're doing analysis — coding qualitative interviews, counting terms, or importing segments into a pipeline.

JSON

The structured export, for when code is the consumer. Each segment is an object with its timing, text and (if enabled) speaker, so an application can read it without parsing timestamps out of a string.

{
  "segments": [
    { "start": 0.498, "end": 2.827, "speaker": "S1",
      "text": "Hello, and welcome to the show." },
    { "start": 2.900, "end": 5.110, "speaker": "S1",
      "text": "Today we're talking about file formats." }
  ]
}

Use JSON when you're building on top of the transcript — a custom viewer, a search index, a summarisation step. It's the loss-less option: everything the transcript knows is in there, ready to reshape into any of the formats above.

The styled subtitle formats: ASS, SSA, SMI, TTML

These carry visual styling the plain formats can't:

ASS / SSA (Advanced SubStation Alpha) — rich positioning, fonts, colours and karaoke-style timing. The standard for anime fansubs and any subtitle that needs to look designed rather than default. Flatten to a universal file with ASS to SRT or SSA to SRT.
SMI (SAMI) — Microsoft's older HTML/CSS-based caption format, still found in legacy Windows Media content. Modernise it with SMI to SRT.
TTML (Timed Text Markup Language) — an XML format used in broadcast and streaming delivery (its profiles include EBU-TT and the SMPTE-TT/IMSC family). Verbose but precise, and standard in professional pipelines. Convert with TTML to SRT.

You rarely author in these unless a platform demands them; more often you receive one and need it as an SRT or VTT.

How to choose, in one line each

Putting subtitles on a video? SRT for broad compatibility, VTT for the web.
Just want to read or quote it? TXT (or PDF/DOCX for a shareable document).
Analysing the transcript? TSV into a spreadsheet.
Building software on it? JSON.
Handed a styled or broadcast file? Convert ASS/SSA/SMI/TTML down to SRT.

Getting the file in the first place

All of these come out of the same step: transcribe the audio or video, then export. ScribeToAny produces TXT, SRT, VTT, TSV, CSV, JSON, PDF and DOCX from one transcript — detect the language automatically, review the segments against the audio, and export as many formats as you need. If you already have subtitle files and only need to move between formats, the browser tools do the conversion on your machine, with nothing uploaded.

Formats are just different views of the same timed text — words, timings, and sometimes styling. Pick the one your destination expects and keep a JSON or a VTT around as the loss-less master. Start from the audio-to-text tool and export into whatever comes next.