Key Takeaways
An SRT file (SubRip Subtitle, extension
.srt) is a plain-text file of subtitles: numbered blocks, each with a start and end time written ashours:minutes:seconds,millisecondsand the text to show. It holds no video or audio, opens in any text editor and is accepted by almost every player and video platform. You can write one by hand, generate it from plain text, or export it from a transcript, then check it with a validator before you upload it.
If you have ever switched on subtitles in a video player, there is a good chance an SRT file was doing the work. It is one of the oldest subtitle formats still in everyday use and one of the simplest file formats there is, which is exactly why it is everywhere.
This page covers the whole format in one place: what is inside a file, the exact rules for each part with the primary sources, how to create and fix one, and how it differs from WebVTT.
What does an SRT file look like inside?
An SRT file is a list of cues, and every cue has the same four parts: a sequence number, a timing line, one or two lines of text, and a blank line. Open any .srt file in Notepad or TextEdit and you will see blocks like these:
1
00:00:01,600 --> 00:00:04,200
Welcome back to the channel.
2
00:00:04,400 --> 00:00:07,900
Today we're looking at how
subtitle files actually work.
3
00:00:08,100 --> 00:00:10,000
<i>(door closes)</i>Read top to bottom, the second cue says: show these two lines from 4.4 seconds to 7.9 seconds into the video. There are no headers, no styling section and no binary data, so the file stays small and survives being opened, edited and saved by almost any program.
What are the rules of the SRT format?
The closest things to a reference for SubRip are the descriptions kept by archives and container formats. The Library of Congress format description gives the timecode as hours:minutes:seconds,milliseconds, written 00:00:00,000, with the arrow --> between start and end, and the Matroska subtitle documentation describes the same four-part block.
| Part | Rule | Example |
|---|---|---|
| Sequence number | A whole number on its own line, starting at 1 and counting up | 2 |
| Timing line | Start and end as hours:minutes:seconds,milliseconds, separated by --> with a space on each side | 00:00:04,400 --> 00:00:07,900 |
| Milliseconds separator | A comma, not a full stop; the full stop belongs to WebVTT | ,400 |
| Text | One or more lines shown together; a line break in the file is a line break on screen | Today we're looking at how |
| Blank line | Ends the cue; the next number starts the next one | (empty line) |
| Formatting | Simple tags such as <i>, <b> and <u>, honoured by many players and ignored by others | <i>(door closes)</i> |
Two details break more files than everything else together. The first is the comma: a timing line written with full stops, 00:00:04.400, is a WebVTT habit, and some tools refuse it in an SRT. The second is the blank line: a cue whose blank line is missing runs into the next one, and the player either merges them or drops one.
Encoding
Save SRT files as UTF-8. It covers every script, from accented Latin letters to Arabic, Chinese and emoji, and it is what current players expect. Files from older Windows tools are sometimes in a regional legacy encoding, which is why accented letters turn into question marks or strings of odd symbols. Re-saving the file as UTF-8 in a text editor fixes that. Some programs also add an invisible byte-order mark at the start of a UTF-8 file; most players ignore it, but if a strict tool rejects the first cue, saving as UTF-8 without the mark is the first thing to try.
Line length is a reading rule, not a format rule
The format itself does not limit how long a line may be; style guides do. The Library of Congress description mentions a 32-character limit per line, the BBC Subtitle Guidelines set 37 characters for broadcast, and the Netflix English (USA) Timed Text Style Guide allows 42 characters per line, two lines at most. A player will show a longer line anyway, usually by wrapping it, so the limit is about whether people can read the subtitle in time, which the reading-speed check in our SRT validator measures against the guide you choose.
What are SRT files used for?
- Video platforms: upload an SRT alongside a video and viewers get captions they can switch on.
- Desktop and TV players: VLC and many other players load an SRT that sits next to the video file with the same name.
- Translation: translators replace the text lines and leave the timing alone, producing one SRT per language.
- Editing software: the common video editors import SRT as a caption track.
- Accessibility: captions for deaf and hard-of-hearing viewers, with sound descriptions in brackets and speaker names, fit in the text lines of an ordinary SRT.
How do I create an SRT file?
From a video automatically
For a YouTube video, paste the link into the YouTube transcript tool and press SRT on the transcript page: the timing comes from the video’s own captions. For your own recordings and files, the SozAI app transcribes the audio in 99 languages and exports subtitles.
From text you already have
If you have a script or a transcript as plain text, the free TXT to SRT generator turns each paragraph into a cue and gives it a duration from its length, at 150 words per minute, never shorter than 2 seconds or longer than 8. Split long paragraphs first: a cue of more than 20 words hits the 8-second cap and comes out too fast to read. It runs in your browser and nothing is uploaded.
By hand
For a short clip, writing an SRT in a text editor is perfectly reasonable: follow the four-part block, save as subtitles.srt in UTF-8, and you are done. Beyond a minute or two of video, timing by hand becomes tedious, and one of the two routes above is faster.
Why does my SRT file not work?
| Problem | Usual cause | Fix |
|---|---|---|
| Subtitles do not show at all | Wrong extension, wrong encoding or a malformed timing line | Run the file through the SRT validator, which names the broken block |
| Subtitles are early or late by the same amount | The video has an intro or a cut the file does not know about | Move every timecode at once with the subtitle time shift tool |
| Subtitles drift further out of sync as the video plays | The file was timed for a different frame rate, for example 23.976 against 25 | See why subtitles fall out of sync |
| Accented letters look garbled | Saved in a legacy encoding | Re-save as UTF-8 |
| The platform rejects the file | It expects WebVTT | Convert with the VTT and SRT converter |
How is SRT different from WebVTT and frame-based timecode?
WebVTT (.vtt) is the W3C format used by HTML5 video players. The W3C WebVTT specification writes the milliseconds after a full stop with three digits and makes the hours optional, and a file starts with a WEBVTT header line; it also adds positioning and styling that SRT does not have. The timing is the same moment written differently, so converting one to the other is a matter of punctuation and headers, covered in more detail in VTT vs SRT.
Video editors count time in frames rather than milliseconds, as SMPTE timecode, HH:MM:SS:FF. An SRT stores real time, so when subtitles are made from an edit’s timecode, the frame rate decides the result: at 29.97 frames per second, an hour of non-drop timecode is 3.6 seconds longer in real time than the label says. Our timecode converter turns SMPTE timecode, including drop-frame, into SRT timestamps and back.
If what you need is the words without any timing, the Subtitle to Text tool strips the numbers and timecodes from an SRT or VTT and leaves readable paragraphs.

