What is an SRT file?

SRT is a plain-text format you can open in any editor. It is used for subtitling.

The extension is .srt, and the full name is SubRip Subtitle. Both matter less than what the file can hold, which is what the rest of this page is about.

It dates from 2000.

Age is worth knowing here for one practical reason: the older a format is, the more programs have had time to learn it.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

SRT stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

VLC, Subtitle Edit and Aegisub read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

SRT is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

It is the simplest useful format on this site. A number on its own line, then a line with two timestamps and an arrow between them, then one or two lines of text, then a blank line. Repeat. That is the entire specification, and it is why every player, editor and platform reads it.

The timestamps are hours, minutes, seconds and milliseconds, written with a comma before the milliseconds rather than a full stop. That comma is the single most common cause of a file being rejected by a strict parser after somebody has edited it by hand, because most of the world writes decimals the other way.

Two different faults, with two different fixes, and telling them apart takes ten seconds. Play the video and check the first subtitle, then check one near the end.

If both are wrong by the same amount, it is an offset — the subtitles were timed against a version of the video with a different beginning, typically because yours has a distributor logo or a longer intro. Shifting every timestamp by the same number of seconds fixes it completely.

If the error grows as the video plays, it is a frame-rate mismatch. The subtitles were made for a 25-frames-per-second broadcast version and your file runs at 23.976, or the reverse, so the two drift apart steadily. That needs a proportional stretch rather than a shift, and no amount of nudging the offset will make both ends right at once.

An SRT file carries no declaration of how its text is stored. There is nowhere in the format to say "this is UTF-8", so the player guesses — and older players guess a regional single-byte encoding, which is why a Spanish or Polish subtitle file arrives full of question marks and boxes.

Save as UTF-8 and most modern players are right. Some older hardware players want the regional encoding instead and will mangle UTF-8. If the text is wrong, the file is usually fine and the reader is misreading it; re-saving in the other encoding is the test worth doing before assuming the download was bad.

No fonts, no colours, no positions, no karaoke timing. Some players honour a handful of HTML-like tags for italics and bold, but that is a convention rather than part of the format, and a file relying on it will look plain somewhere.

Everything visual is decided by the player: where subtitles sit, how large they are, what colour the outline is. This is why SRT files are tiny and universally compatible, and it is why anyone doing real subtitle design uses ASS instead, where position, font and effects are part of the file.

Most desktop players load subtitles automatically when the file sits next to the video with the same name — film.mp4 and film.srt in the same folder. Get the name wrong by a single character and nothing appears, which accounts for a large share of "my subtitles do not work".

A language suffix before the extension, as in film.en.srt, is the usual convention for several languages and is understood by the common players. Beyond that: some televisions and media boxes only read subtitles from a USB stick if they are on the same partition as the video, and almost none of them read anything but SRT.

WebVTT is the format browsers use for subtitles on a web page, and it is closely related — the structure is nearly identical, the timestamps use a full stop instead of a comma, and the file begins with a header line. Converting between the two is mostly mechanical.

The rule is simple. Video on a website needs VTT, because that is what the HTML video element accepts. Video played in a desktop player, on a television, or uploaded to a platform wants SRT. Converting takes a moment, so keep whichever one your workflow produces and convert at the point of delivery rather than maintaining two copies that will drift apart.

Any text editor. The file is text, the structure is obvious, and fixing a typo or shifting one late caption is faster there than in a subtitle editor. Save as UTF-8 without a byte-order mark and keep the blank line between entries — a missing blank line makes everything after it disappear in strict players.

For anything systematic — shifting the whole file, changing the frame rate, resyncing against a waveform — a dedicated subtitle editor earns its keep. Doing an offset by hand across nine hundred timestamps is possible in a text editor and is not a good use of an evening.