What is an SRT file?

The structure of an SRT file

An SRT is plain text made of repeating blocks. Each block has four parts, in this order: a sequence number on its own line, a timing line, one or two lines of subtitle text, and a blank line separating it from the next block. That is the entire format.

How the timecodes work

Times are written as hours, minutes, seconds, and milliseconds, with a comma before the milliseconds rather than a period. The comma is a European decimal convention inherited from the original tool, and it is the detail that most often trips people converting between formats. WebVTT, which otherwise looks almost identical, uses a period instead.

• Hours are always two digits, even when there are none, so a subtitle one second in starts at 00:00:01,000.
• Times are measured from the start of the video, not from the start of the file.
• Blocks are expected to be in chronological order. Out-of-order blocks are undefined behaviour and players disagree about what to do with them.
• Overlapping times are also undefined. Some players stack the text, some drop one, some flicker between them.

What SRT deliberately leaves out

SRT carries words and times. It does not carry position, font, size, colour, or alignment in any standardised way. Some players honour a small set of HTML-like tags for bold, italic, and underline, but nothing guarantees it. That gap is the whole reason richer formats exist, and the whole reason SRT is universally supported: there is almost nothing in it to disagree about.

Encoding, which is where files actually break

The format predates the assumption that text is Unicode, and it stores no declaration of its own encoding. A player has to guess. If a file is saved as anything other than UTF-8, accented Latin characters turn into pairs of nonsense symbols and non-Latin scripts turn into unreadable noise on any machine that guesses differently from the one that wrote it.

• Save as UTF-8. Every modern player handles it, and it covers every script.
• Avoid a byte order mark if you can. Most players cope, but a few show a stray character at the start of the first subtitle.
• If a file arrives with mangled accents, it is almost always an encoding mismatch rather than a corrupted file, and re-saving it with the right encoding recovers it.

When SRT is the right choice

• Whenever you need something to load somewhere you do not control. Nothing else is as broadly supported.
• As the master copy of your subtitles. It is plain text, so it diffs, edits, and survives without special tools.
• As the input to translation, because the timings are preserved and a translated file drops onto the same video.

It is the wrong choice when placement or styling actually matters, when you need speaker identification carried in the file, or when the destination is a social feed that will not read a subtitle file at all. For that last case, see burned-in vs soft subtitles.