SRT file example: the format, line by line

SRT is a plain text format. Open one in any text editor and this is what you see. Here are the first five cues of a real caption file.

1

00:00:01,120 --> 00:00:03,880

Right, so this is the bit everyone

has been asking about.

2

00:00:04,010 --> 00:00:07,450

I am going to open a project that

already has four takes in it.

3

00:00:07,880 --> 00:00:11,200

Four takes, and the third one is

the good one.

4

00:00:11,640 --> 00:00:14,300

Which you cannot tell by looking

at it. That is the whole problem.

5

00:00:15,000 --> 00:00:17,760

- And previously you would have

- had to listen to all four.

Each cue has four parts in a fixed order: a sequence number on its own line, a timecode line, one or two lines of text, then a blank line. The blank line is not decoration — it is how a parser knows the cue has ended.

The sequence number counts from 1 and increments by one. It is not a timestamp and it is not optional. Some players tolerate gaps in the sequence; plenty do not.

The timecode is hours:minutes:seconds,milliseconds with a comma before the milliseconds, an arrow of exactly two hyphens and a greater-than sign, and spaces either side of the arrow. All four are strict. A full stop instead of the comma is the single most common reason an SRT file fails to load.

Hours are always two digits, even at the start of a file: 00:00:01,120, never 0:00:01,120.

The hyphen at the start of each line in cue 5 marks two different speakers in the same cue. It is a convention rather than part of the specification, but it is widely understood and worth using.

Two lines per cue, maximum. Three is possible and looks cramped on a phone; it also covers more of the picture than anyone wants.

Around 42 characters per line is the broadcast convention, and it holds up well on the web. Longer lines either shrink or wrap unpredictably depending on the player.

A cue needs at least a second on screen to be readable and should rarely exceed seven. Under a second reads as a flicker; over seven and the caption has stopped matching the audio.

Break lines at grammatical joints, not at whatever word hits the character limit. "Right, so this is the bit everyone / has been asking about" breaks between subject and verb phrase. "Right, so this is the bit every- / one has been asking about" does not, and the reader stumbles.

Never let cues overlap in time. Two cues claiming the same second is undefined behaviour, and different players resolve it differently.

A full stop instead of a comma before the milliseconds. This is the one. 00:00:01.120 is VTT syntax, not SRT.

A missing blank line between cues. The parser reads the next sequence number as a third line of caption text and everything after it drifts.

A byte order mark at the start of the file, usually added by a Windows text editor saving as UTF-8. Save without it.

An end time earlier than its start time, which usually happens after someone hand-edits timings. Most players skip the cue silently, so the caption simply never appears and nothing tells you why.

SRT has no styling. Some players honour basic bold and italic tags, many ignore them. If the file must carry positioning or styling, use VTT instead.

Transcribe first, correct the transcript, then export SRT from the corrected version. Exporting captions from raw machine output means fixing the same errors twice, once in the transcript and once in every cue.

The video below covers generating and downloading the transcript, which is the step before the export.