The SRT file format, explained
SubRip (.srt) is the most widely supported subtitle format in the world. It has no formal specification — just a simple, near-universal convention. Here is exactly how it is structured and where it goes wrong.
SRT stands for SubRip Subtitle, after the Windows program SubRip that popularised it by extracting subtitles from DVDs in the early 2000s. It became the default subtitle format precisely because it is so plain: a numbered list of timed text blocks in a UTF-8 text file. Almost every video player, editor, smart TV and media server reads it.
There is no official standard — no W3C recommendation, no RFC. The format is defined by convention and by what players accept. That looseness is its strength (it is trivial to write) and its weakness (subtly malformed files are everywhere). This page documents the convention precisely.
The structure of a cue
An SRT file is a sequence of cues (also called subtitle blocks), each made of four parts:
1 ← sequence number (1-based)
00:01:14,800 --> 00:01:17,200 ← start --> end timestamp
<i>Are you there?</i> ← one or more lines of text
It's me.
← a blank line ends the cue
2
00:01:18,000 --> 00:01:20,500
Of course I'm here. - Sequence number — a counter starting at 1, incrementing by one. Players largely ignore the value but expect the line to be there.
- Timestamp line — start and end, separated by
-->(space, two hyphens, greater-than, space). - Text — one or more lines. A line break inside the cue becomes a line break on screen.
- Blank line — a single empty line marks the end of the cue. This separator is mandatory; its absence is the most common reason a file fails to parse.
The timestamp format
Timestamps are always HH:MM:SS,mmm:
- Hours, minutes, seconds — two digits each, zero-padded.
- Milliseconds — three digits, after a comma. The comma decimal separator is the single most distinctive feature of SRT; WebVTT uses a period in the same place, and mixing them up is a frequent error.
- Range — the start must be before the end. The end of one cue may equal or precede the start of the next; they should not overlap, though many players tolerate it.
In practice you also encounter hour fields longer than two digits on very long files, and stray periods instead of commas from sloppy exporters. A forgiving parser (like the one behind these tools) accepts both and normalises them; a strict player may reject them.
Formatting: the limited tag set
SRT carries plain text, but a small set of HTML-style tags is widely honoured for inline styling:
<b>…</b>— bold<i>…</i>— italic (by far the most used, for off-screen or emphasised speech)<u>…</u>— underline<font color="#ffcc00">…</font>— colour, honoured by some players (VLC, MPC-HC) and ignored by others
Everything beyond this is non-standard. There is no official syntax for positioning, fonts or karaoke — those belong
to ASS/SSA. Some players honour an extension like {\an8} at the
start of a line to move a cue to the top of the screen, but it is a convention, not part of SRT.
Encoding: the silent killer
SRT files store no declaration of their own character encoding. For years they were saved in regional Windows code
pages — Windows-1251 for Cyrillic, Windows-1256 for Arabic, and so on — and a player had to guess. Modern players
assume UTF-8, so an old regionally-encoded file shows up as mojibake:
здравеÐthemed garble or the replacement character �.
The fix is to re-save as UTF-8. A leading byte-order mark (BOM) is optional; most players don't need it, and a few older ones choke on it, so UTF-8 without BOM is the safest default. If your subtitles look scrambled, the encoding fixer detects the original and rewrites clean UTF-8.
The faults that break SRT files
Because the format is so permissive, broken files are common. The recurring problems:
- Missing blank line between cues — the parser runs two cues together.
- Out-of-order or duplicate numbering — usually harmless, but some players bail.
- Comma/period mix-up in timestamps.
- Overlapping or negative durations — an end time before its start.
- Unclosed tags — an
<i>with no</i>can italicise the rest of the file. - Wrong encoding — covered above.
The SRT validator and repair tool detects every one of these and fixes the structural ones in a single pass, while only flagging judgement calls like lines that are too fast to read.
When SRT is the right choice
Choose SRT whenever maximum compatibility matters and you don't need styling or positioning: desktop players, smart TVs, media servers like Plex and Jellyfin, and as the interchange format for editing or embedding into an MKV. When you need it for an HTML5 web player instead, convert to WebVTT — see the SRT vs VTT comparison for the full trade-off.