What Is an SRT File? Format, Structure and Common Mistakes Explained

If you have ever downloaded subtitles for a film, a lecture, or a video you edited yourself, there is a good chance the file ended in .srt. It is the most widely supported subtitle format in the world, and it is also one of the simplest. You can open it in any text editor and understand it in a minute.

That simplicity is the reason SRT survived for more than two decades while fancier formats came and went. It is also the reason small mistakes, such as a missing blank line or a period where a comma should be, can stop a file from loading. This guide explains exactly what is inside an SRT file, how players read it, what it cannot do, and how to avoid the most common errors. Each part of the format is explained with a short example.

Where the name comes from

SRT stands for SubRip Text. SubRip was a Windows program from the early 2000s that extracted subtitles from DVDs by recognising the pictures of text and turning them into plain text. The program saved its output in a very plain format, and that format took on the program's name. Today the format is supported by practically every video player, television, phone, video editor, and online video platform, even though there is no single official standard document for it. Because it grew out of common practice rather than a formal specification, small differences between programs exist, which is why robust tools are forgiving about what they accept.

The anatomy of an SRT file

An SRT file is a plain text file made of subtitle blocks, one after another. Each block has the same four parts:

1. A sequence number, counting from 1.
2. A timecode line that says when the subtitle appears and disappears.
3. One or more lines of subtitle text.
4. A blank line that marks the end of the block.

Here is a short example:

1
00:00:01,000 --> 00:00:03,200
Did you bring the map?

2
00:00:03,500 --> 00:00:05,800
It's in my coat pocket.

3
00:00:06,000 --> 00:00:08,400
Then we leave
before sunrise.

Let us look at each part in turn.

The sequence number

The first line of each block is a whole number. In a clean file the numbers run 1, 2, 3 with no gaps and no repeats. Most players do not actually use the number for anything important and decide the order by the timecodes, but some strict programs and online platforms reject files where the numbering is broken. When you merge or edit subtitles, renumbering the blocks from 1 is the safe choice, and it is what the subtitle merging tool does automatically when it saves.

The timecode line

The second line holds two times separated by an arrow made of two hyphens and a greater-than sign: -->. The format of each time is hours, minutes, seconds, and milliseconds, written HH:MM:SS,mmm.

Two details trip people up:

• The separator before the milliseconds is a comma, not a period. WebVTT, a related web format, uses a period, and mixing the two up is the single most common reason a converted file fails to load.
• The milliseconds always have three digits. 00:00:01,5 is not the same as 00:00:01,500, and some programs read it differently.

The first time is when the subtitle appears. The second time is when it disappears. Everything between them is the duration. A well-timed subtitle usually stays on screen for at least about one second and rarely longer than around seven.

The subtitle text

Everything after the timecode line, up to the next blank line, is the subtitle text. It can run over one, two, or occasionally more lines. A line break in the file becomes a line break on screen, so how you break the text in the file is how viewers will see it.

The blank line

A completely empty line ends the block. This is not optional. If the blank line is missing, a parser may treat the next sequence number as part of the previous subtitle's text, and you will see stray digits on screen. If you have extra blank lines inside the text of a single subtitle, the opposite happens: the subtitle is split in two and the second half loses its timecode. Keep text lines tight and use exactly one blank line between blocks.

Formatting tags

SRT has no official styling system, but nearly every player understands a small set of tags borrowed from HTML:

Tag	Effect	Typical use
<i>text</i>	Italic	Off-screen voices, thoughts, foreign words, titles
<b>text</b>	Bold	Emphasis, rarely
<u>text</u>	Underline	Rarely used
<font color="#ffff00">text</font>	Colour	Speaker identification in some releases

Support varies. Italics are close to universal. Colours work in many desktop players but are ignored by some televisions and by web players, and they are a poor choice if your audience may use accessibility settings that override subtitle colours. If you need precise positioning, fonts, or effects, SRT is the wrong format and you should look at ASS or at the cue settings in WebVTT. We compare them in SRT vs VTT vs ASS.

Some programs also accept position codes such as {\an8} at the start of a line, which place text at the top of the screen. These are extensions that belong to other formats and not part of plain SRT, so do not count on them being understood everywhere.

Line endings and text encoding

Two invisible details decide whether a file works on a given device.

Line endings. Windows traditionally ends each line with two characters (carriage return and line feed), while Linux and macOS use one (line feed). Almost every modern player accepts both. If a file looks like one giant line in an old editor, a line ending mismatch is the cause. Our merger writes Windows-style endings, which every mainstream player accepts.

Encoding. This is how characters are turned into bytes. UTF-8 is today's standard and handles every language. Older files, especially from before 2010, may use a regional encoding such as Windows-1252 for Western European languages, Windows-1251 for Cyrillic, or Windows-1256 for Arabic. If you open one of those files as UTF-8, accented letters and non-Latin scripts turn into question marks or strange symbols. Some UTF-8 files also begin with an invisible marker called a byte order mark. Good software ignores it, but a few strict tools show it as a stray character on the first line. We cover diagnosis and conversion in fixing garbled subtitles.

What SRT cannot do

Knowing the limits of the format saves time:

• No standard styling. Fonts, sizes, and outlines are controlled by the player, not the file.
• No guaranteed positioning. Subtitles normally appear at the bottom centre. Anything else is an extension.
• No metadata. There is no place for language, author, or frame rate inside the file.
• No images. SRT is text only. Subtitles stored as pictures, as on DVDs and Blu-rays, need to be converted by optical character recognition first.
• Time-based, not frame-based. SRT stores milliseconds, so it is independent of the video's frame rate. That is a strength, but it also means a frame rate change in the video requires re-timing the file.

The most common mistakes

Here are the problems you are most likely to meet, with the quick fix for each.

Periods instead of commas in the timecode. 00:00:01.000 is WebVTT style. Replace the period with a comma, or let a conversion tool do it.

End time earlier than start time. The subtitle will never display. Open the file and correct the times.

Overlapping subtitles. Two blocks that share a moment on screen will draw on top of each other in some players. Overlaps are sometimes intended, as when two people speak at once, but accidental overlaps look messy. Shorten the first subtitle so it ends just before the next begins.

Very long lines. The widely used guideline is no more than about 42 characters per line and two lines per subtitle. Longer lines get cut off or shrink on small screens. See subtitle formatting best practices.

Blank line problems. A missing separator merges two subtitles; an extra one splits a subtitle. Check around any block that looks wrong.

Wrong encoding. If accents look broken, convert to UTF-8.

Wrong file extension. A WebVTT or ASS file renamed to .srt is not an SRT file. Open it in a text editor. If the first line says WEBVTT or you see sections in square brackets, it is another format.

How to open and edit an SRT file

Because it is plain text, any editor will do, including Notepad, TextEdit in plain-text mode, or a code editor. For more than a handful of edits, a dedicated subtitle editor is much easier because it shows the video and the waveform next to the text. Free programs such as Subtitle Edit and Aegisub are popular for this. For comparing and combining two files, a browser tool such as the free merging tool saves you from doing it by hand.

When editing in a text editor, save the file as UTF-8 and keep the name ending in .srt. If your player loads subtitles automatically, give the file the same base name as the video, for example film.mp4 and film.srt, and keep both in the same folder. Language-coded names such as film.en.srt are understood by many players as well.

Creating an SRT file from scratch

You can write one by hand in a text editor in a few minutes. Start with the block structure above, play the video, and note the time each line starts and ends. Work in small batches and test often. It is slow, but it is a good way to understand the format, and it helps you recognise problems when you see them in someone else's file.

For longer videos, most people transcribe the audio first, either by hand or with speech recognition, and then use an editor to set the timing. Many video platforms can export an automatically generated SRT as a starting point. Automatic captions always need a human pass, because names, jargon, and punctuation are frequently wrong.

Key takeaways

An SRT file is a plain text list of numbered blocks. Each block has a number, a start and end time written with a comma before the milliseconds, one to two lines of text, and a blank line after it. It supports only a few simple tags, so it is reliable but basic. Most problems come from timecode punctuation, blank lines, and text encoding, all of which you can check in a text editor in seconds.

Once you know these rules, subtitle files stop being mysterious. You can open any broken file, find the faulty block, and fix it, and you will understand what your tools are doing when they merge, convert, or re-time a file for you.