SRT File Documentation

Summary

An SubRip Subtitle file is a plain-text file that stores the timed captions for a video: numbered cues, each with a start and end timecode and the lines to display. It uses the MIME type application/x-subrip and the extension .srt. Any text editor opens it, and most players load it automatically when the .srt shares the video’s name and folder (movie.mp4 + movie.srt).

Technical details

FeatureValue
Full nameSubRip Subtitle File
File extension.srt
MIME typeapplication/x-subrip
Format typePlain-text timed subtitles
OriginSubRip program (by Zuggy), c. 2000
Character encodingUTF-8 (recommended); legacy ANSI / code pages also seen
Byte-order markOptional UTF-8 BOM EF BB BF at offset 0 (not required; can confuse some players)
Cue indexSequential integer, starting at 1
Timecode formatHH:MM:SS,mmm --> HH:MM:SS,mmm (comma before milliseconds)
Time resolutionMillisecond
Cue separatorOne blank line between blocks
Inline stylingLimited: <i>, <b>, <u>, <font color>
PositioningNon-standard X1/Y1 coordinate extension, rarely supported
MetadataNone — no header, no comment syntax
Signature (magic bytes)None (plain text)
Open standardDe facto; no formal specification body
Related extensions.vtt, .ass, .ssa, .sub, .sbv
Referenceen.wikipedia.org/wiki/SubRip
Structure at a glance

An .srt is plain UTF-8 text with no signature. It is a list of cues separated by blank lines. Each cue is four parts on consecutive lines: a sequence number (1, 2, 3…), a timecode line 00:01:12,500 --> 00:01:15,000 using a comma before the milliseconds and a --> arrow, one or more text lines, then a blank line. Optional inline tags <i>, <b>, <u> and <font color> give limited styling. There is no header and no comment syntax.

What is an SRT file?

SRT is short for SubRip Subtitle, the most widely used subtitle format in the world. It comes from SubRip, a Windows program written by a developer known as Zuggy around the year 2000, whose job was to rip subtitles off DVDs into a plain-text file. That saved file took the .srt extension, and the format was simple enough that it outlived the program and became the de facto standard for captions and subtitles. There is no formal standards body and no published specification; the format is defined by convention and by what the SubRip tool wrote.

An SRT file contains no video and no audio. It is a list of cues, each pairing a span of time with the text to show during that span. Because it is just UTF-8 text, an .srt is tiny, opens in any editor, and is read by almost every media player, video editor and streaming platform. The rest of this page is about the exact syntax of a cue, how timecodes work, the encoding pitfalls that cause the “strange characters” problem, and how SRT relates to the web caption format WebVTT.

Anatomy of a cue: number, timecode, text, blank line

The structure is straightforward and rigid. Each cue is a block of consecutive lines, and blocks are separated by a single empty line:

1
00:00:01,000 --> 00:00:03,000
This is the first subtitle.

2
00:00:04,000 --> 00:00:06,000
This is the second subtitle,
split across two lines.

The first line of a block is a sequence number, an integer that conventionally starts at 1 and increments by one. Most parsers treat it as informational rather than authoritative: the cue’s actual timing comes from the timecode line, not from its index. The second line is the timecode, which sets when the text appears and disappears. Every line after that, up to the next blank line, is subtitle text; a hard line break in the file becomes a line break on screen, so a two-line caption is written as two lines. A single blank line terminates the block. That blank line is the only delimiter, which is why an accidental empty line inside a caption, or a missing one between cues, is the most common cause of a broken SRT.

The timecode line: HH:MM:SS,mmm and the comma

The timecode line is the part with the strictest syntax:

00:01:12,500 --> 00:01:15,000
│  │  │  │      │
│  │  │  │      └─ end time, same format
│  │  │  └─ milliseconds (000-999), THREE digits
│  │  └─ seconds (00-59)
│  └─ minutes (00-59)
└─ hours (zero-padded, usually two digits)

Both the start and end times use HH:MM:SS,mmm: hours, minutes and seconds separated by colons, then a comma before a three-digit millisecond field. The two times are joined by a space, the arrow --> (two hyphens and a greater-than sign), and another space. The millisecond field gives SRT its resolution: timing is accurate to one thousandth of a second. The comma is the detail that trips people up, because it is the single most important difference from WebVTT, which uses a full stop in the same position. A player expecting one separator will often reject a file that uses the other, and a find-and-replace of , for . in the timecodes is a large part of what an SRT-to-VTT conversion actually does.

Timecodes are meant to be non-overlapping and in order, but nothing in the plain-text file enforces that. Two cues whose times overlap will display on top of each other in many players; a cue whose end time precedes its start simply never shows. Because the format has no duration field, the on-screen time of a caption is always the end minus the start.

Inline styling: the four tags SRT understands

SRT borrows a small set of HTML-like tags for styling inside the text lines. Four are widely recognised: <i> for italics, <b> for bold, <u> for underline, and <font color="#ffcc00"> for colour.

3
00:00:07,000 --> 00:00:09,500
<i>He whispered</i> something
<font color="#ff0000">in red.</font>

That is the whole styling vocabulary. There is no font-family control, no size, no outline or shadow, and no reliable way to position text on screen. Some tools accept an X1/Y1/X2/Y2 coordinate extension appended to the timecode line, but support for it is rare and inconsistent, so it is not safe to rely on. Anything richer, positioned karaoke, per-word timing, styled boxes, belongs to Advanced SubStation Alpha (.ass/.ssa), which is why a subtitle author who needs real typography converts the SRT to ASS and adds styles there.

Encoding, the BOM, and the “strange characters” problem

SRT predates the assumption that everything is UTF-8, and its encoding is not declared anywhere in the file. A modern .srt should be saved as UTF-8 so that accented letters and non-Latin scripts display correctly. Files created by older tools are often in a legacy code page (Windows-1252, or a regional ANSI page), and when such a file is read as UTF-8 the accented characters turn into mojibake, the classic symptom of a subtitle full of é and  sequences. There is no metadata to signal which encoding was used, so a player has to guess, and re-saving the file as UTF-8 in an editor is the fix.

A UTF-8 byte-order mark (EF BB BF) may appear at offset 0. It is legal, but it is not required and can cause trouble: a naive parser that reads the first line looking for the number 1 may instead see the three BOM bytes glued to that 1 and fail to recognise the first cue. Because of that, many subtitle tools strip the BOM on save.

How players pair an SRT with its video

An SRT is almost never opened on its own; it is loaded alongside a video. The universal convention is to give the subtitle file the same base name as the video and keep the two in the same folder: Film.2024.mkv pairs with Film.2024.srt, and a language tag can be added as Film.2024.en.srt. Players such as VLC, MPV and Kodi scan the video’s folder for a matching name and load the subtitles automatically; dragging the .srt onto a playing video does the same thing manually.

Making subtitles part of a video is two different operations that are easy to confuse. Soft-muxing adds the SRT as a selectable subtitle track inside a container such as MKV or MP4; the text stays text, the track can be turned on and off, and no video is re-encoded. Burning in (hardsubbing) renders the characters into the video’s pixels during a re-encode, so the subtitles become part of the picture, cannot be turned off, and play on any device that plays the video. The first is lossless and reversible; the second is neither, but it needs no subtitle support in the player.

Frequently asked questions

Why does the timecode use a comma before the milliseconds?

It is a quirk of the original SubRip program, which was written in a locale that used the comma as a decimal separator. The format froze that choice. It is the main syntactic difference from WebVTT, which uses a full stop, and it is why converting between the two formats always involves swapping that character in the timecode lines.

What is the difference between SRT and VTT?

WebVTT (.vtt) is the caption format for HTML5 <track> elements. It is nearly identical to SRT but adds a WEBVTT header line, uses a full stop instead of a comma in timecodes, drops the mandatory cue numbers, and supports richer positioning and styling cues. A basic SRT converts to VTT by adding the header and changing the decimal separator.

Do the sequence numbers have to be correct?

In practice, no. Most players key off the timecodes and ignore or renumber the indices, so an out-of-order or duplicated number rarely stops playback. They exist for human readability and for tools that merge or reorder cues; a strict validator will still flag them.

References