Caption Format Reference
SRT File Format (.srt)
SRT is the most widely supported subtitle format in the world and the least capable. It carries text and timing, and almost nothing else. That combination is why it travels everywhere, and why converting out of it is harder than converting into it.
What can an SRT file be converted to?
An SRT file can be converted to any caption or subtitle format, because every format can hold more than SRT does. The difficulty runs the other way: SRT carries no positioning, styling or frame rate, so a converter has to supply all three when the target is SCC, MCC, EBU-STL or PAC.
SRT at a glance
SRT has no governing standard. It is defined by what the original SubRip application wrote and what every player since has agreed to accept, which is why parsers disagree at the edges.
| Property | Value |
|---|---|
| Full name | SubRip Subtitle |
| Extension | .srt |
| Specification | None. A de facto standard set by the original SubRip application |
| File encoding | Undeclared. UTF-8 in modern practice, Windows-1252 in older files |
| Timing | Millisecond precision, written HH:MM:SS,mmm with a comma |
| Frame rate | None. SRT is frame-rate agnostic |
| Timing model | Explicit start and end time on every subtitle |
| Positioning | None |
| Styling | None in the format. HTML-style tags are a convention |
| Structure | Numbered blocks separated by a blank line |
| Closed Caption Creator | Read and write |
For a side-by-side of what each format holds, see the full file format support list.
What SRT can and cannot carry
The short list of what fits inside an SRT file is short on purpose. Anything not in this table has to be recreated downstream, usually by a person making a judgement call.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | Any script, provided the file is UTF-8 |
| Explicit end times | Yes | Every subtitle carries both a start and an end |
| Line breaks | Yes | A newline inside the subtitle block |
| Italics, bold, underline | Convention only | <i>, <b> and <u> are honoured by most players but appear in no specification |
| Text colour | Convention only | <font color> works in some players and is silently ignored in others |
| Positioning | No | Some tools append X1/Y1 coordinates, a VobSub extension most players discard |
| Speaker identification | No | Written into the text itself, as a hyphen or a name in brackets |
| Frame-accurate timing | No | Milliseconds do not align to a frame boundary |
| Two languages in one file | No | One language per file |
| Caption channels | No | There is no channel concept |
| Metadata | No | No header, no title, no language tag, no frame rate |
Who asks for SRT files?
SRT is the format people ask for when they have not specified a delivery path. It is the safe default because almost nothing rejects it.
- YouTube, Vimeo and social platforms, where an SRT upload is the standard route to captions.
- Translation and localisation vendors, who use it as a neutral interchange format between tools.
- Editors and NLEs importing subtitles into a timeline.
- OTT platforms that accept SRT as a mezzanine and generate their own delivery format from it.
- Corporate and education video, where broadcast placement rules do not apply.
Broadcast is the exception. North American playout expects SCC or MCC, and European broadcast expects EBU-STL. None of them accept SRT as a deliverable.
How do I open an SRT file?
An SRT file opens in any text editor and is immediately readable. Unlike a broadcast caption file, there is nothing to decode — you see the subtitle number, the timecodes, and the text exactly as written.
That readability is why hand-editing an SRT is common and why it so often goes wrong. Deleting a blank line between blocks, or renumbering incorrectly, breaks strict parsers even though the file still looks fine.
If the text opens with accented characters replaced by symbols, the problem is encoding rather than the file being corrupt. Re-open it as UTF-8, or as Windows-1252 if the file predates 2010, and the characters return.
Converting SRT to another format
This is the hard direction. Every target format has fields SRT never filled in, so a converter either leaves them empty or picks a default. Knowing which is which is the difference between a clean delivery and a rejected one.
| Convert SRT to | What survives | What to watch for |
|---|---|---|
| WebVTT | Text, line breaks, italic tags | Close to one-to-one. Commas become periods, a WEBVTT header line is added, and font tags need to become CSS classes. |
| SCC | Text and line breaks | Placement, 32-character wrapping and a 29.97 fps timing base all have to be created. Check the default row before delivery. |
| MCC | Text and line breaks | As SCC, plus a decision about which 708 service to populate and at what frame rate. |
| TTML / IMSC | Text and line breaks | A region and style model has to be authored. The default region decides where every subtitle lands. |
| EBU-STL | Text | A 25 fps timing base and a teletext row assignment. Lines longer than the teletext limit will be re-wrapped. |
| PAC | Text | A code page must be chosen for the target language, and timing converts from milliseconds to frames. |
| Burnt-in video | Text | Font, size, position and outline are all new decisions. Nothing in the SRT constrains the look. |
Converting another format to SRT
Converting into SRT is straightforward and always lossy. The text and timing come across; everything that positioned or styled the captions is discarded, because SRT has nowhere to put it.
| Convert to SRT from | What carries over | What the conversion has to decide |
|---|---|---|
| WebVTT | Text, line breaks, italic tags | Cue settings and CSS styling are dropped. Periods become commas and the WEBVTT header is removed. |
| SCC | Text and line breaks | End times. SCC has no duration field, so each subtitle's end has to be derived from the next erase command. |
| MCC | Text and line breaks | Which caption service to read, then the same end-time derivation as SCC. |
| TTML / IMSC | Text and line breaks | Styling and region data are dropped, and multi-region layouts flatten into one stream in reading order. |
| EBU-STL | Text and line breaks | Teletext colour and row data are dropped, and frame timing converts to milliseconds. |
| PAC | Text | The source code page has to be read correctly, or non-Latin text arrives as mojibake. |
| Transcript (DOCX, TXT, CSV) | Text | Everything. A transcript has no timing, so subtitles have to be timed before an SRT can exist. |
Closed Caption Creator reads and writes every format in both tables. See the full file format support list, or the conversion API and CLI for batch workflows.
Where SRT files go wrong
SRT has no validator, no schema and no required header, so broken files look normal until something refuses to read them.
- Comma versus period. SRT writes milliseconds after a comma; WebVTT uses a period. A file with the wrong separator fails in strict readers and silently mistimes in lenient ones.
- Undeclared encoding. There is no encoding field. A Windows-1252 file read as UTF-8 turns every accented character into mojibake.
- Overlapping timecodes. Nothing prevents one subtitle starting before the previous one ends. Some players stack both on screen, others drop one without warning.
- Assumed styling. Italic and colour tags are conventions, not specification. A file that depends on them will look different in every player.
For delivery checks across formats, see how to QC closed captioning and subtitles, and subtitle reading speed for the timing rules most specs enforce.
SRT conversion questions
Common questions about moving subtitles into and out of the SubRip format.
Not in any specification. Some tools write X1/Y1 coordinates onto the timing line, an extension inherited from VobSub, and most players ignore them. Colour through <font> tags is honoured by some players and dropped by others. If placement or colour matters to your delivery, SRT is the wrong container and WebVTT or TTML is the right one.
Because SRT carries no encoding declaration, so the reader has to guess. A file saved as Windows-1252 and opened as UTF-8 shows accented characters as pairs of symbols. Re-opening it with the correct encoding restores the text. Saving as UTF-8 without a byte order mark is the safest choice for new files.
Yes, but treat the output as a draft rather than a finished deliverable. SRT supplies no placement, so every caption lands on a default row, and lines are re-wrapped to fit 32 characters. Timing is rebased to 29.97 fps. Review placement over lower thirds and on-screen text before the file goes to playout.
WebVTT is a specified format with a required header, mandatory UTF-8 encoding, cue settings for positioning, and CSS-based styling. SRT has none of those. In practice a WebVTT file that uses no cue settings is an SRT with periods instead of commas, which is why conversion between them is close to lossless in one direction and lossy in the other.
No, and that is usually an advantage. SRT stores milliseconds rather than frames, so the same file plays correctly against 23.976, 25 and 29.97 fps video. Frame rate only becomes a problem when converting into a frame-based format such as SCC or EBU-STL, where a rate has to be chosen.
No. There is no language field and no channel concept, so two languages in one file simply appear as two subtitles at the same timecode. Deliver one SRT per language and name the files with a language code.
Take SRT anywhere it needs to go
Closed Caption Creator imports SRT and exports to 30+ caption and subtitle formats, adding the placement, wrapping and frame-rate base that broadcast targets require.
Conform timing, QC reading speed and line length, and check the result before it goes out.