What is an SRT file? Inside the plain-text subtitle format

The SRT file format, line by line

An SRT file stores subtitles as plain text. Each cue has three parts: a sequence number, a timestamp line and the text that appears on screen. A blank line separates one cue from the next. That is the whole structure. There are no required fonts, colours, positioning values or metadata blocks. Because the format is so small, you can open a subtitle file in Notepad, VS Code or any text editor and understand it without special software.

The number above each cue is a counter, not an identifier that you reference elsewhere. Players sort cues by their timestamps, so cue 7 can sit above cue 6 in the file and still play in the right order. Editors and validators, however, expect the numbers to run in sequence, and a missing number can confuse older parsers. When you edit by hand, renumbering from 1 is the safest habit.

• Cue number: an integer, usually starting at 1.
• Timestamp line: start and end times separated by -->.
• Text: one or more lines shown together.
• Blank line: the separator between cues.

Timestamps, commas and why SRT uses a comma

The timestamp line follows a fixed pattern: hours, minutes, seconds and milliseconds. Milliseconds are separated from the seconds by a comma, and the two times are joined by a space, two hyphens, a greater-than sign and another space. A typical line reads 00:00:12,480 --> 00:00:15,200. Hours are written as two digits, and the field is not optional in the common form.

The comma is a historical choice, not a technical necessity. Early subtitle tools used it, and the habit spread before anyone wrote a formal specification. Some modern utilities accept a dot, and many parsers are lenient, but a comma is what other tools expect. If a file is renamed from .srt to .vtt without fixing the comma, strict WebVTT parsers can reject it.

Timestamp precision matters more than it looks. Rounding to whole seconds makes cues feel late, especially for rapid dialogue. Keeping three decimal places gives you millisecond control, which is enough for frame-accurate work at common frame rates. If two cues touch at exactly the same millisecond, many players show a brief flicker; leave a small gap or merge them into one cue.

There is no single official SRT specification

SRT is often described as a format with no official standard, and that description is accurate. It grew through use rather than through a committee. Different tools have added unofficial extensions: coordinates for positioning, tags for italics, and non-standard timestamp variants. A player may honour those extensions or ignore them, and both behaviours are common.

The practical consequence is that a file can be valid to one tool and invalid to another. A file with <i> tags may look right in VLC and show literal angle brackets in a web player. A file with position coordinates may render correctly in one editor and as stray numbers in another. When a client asks for a guaranteed-compatible file, keep the content plain and test in the destination player.

Because there is no central authority, the best test is behavioural: open the file, play the video and watch. Syntax checkers catch malformed timestamps and overlaps, while playback reveals how a specific app treats optional markup. Treat any extension outside cues and timestamps as a local convention until you confirm it on the target system.

UTF-8 SRT: encoding, BOM and special characters

UTF-8 is the safest encoding for any subtitle file that contains more than basic English. It can represent Arabic, Hindi, Chinese, Japanese, Korean, Cyrillic and accented Latin text without switching code pages. Most modern editors save UTF-8 by default, but older Windows tools may still offer ANSI or a local encoding in the Save As dialog. Choose UTF-8 explicitly when the option exists.

The byte-order mark is a separate decision. A BOM is an invisible signature at the start of the file. Windows Notepad has historically added one, and some players treat it as part of the first cue number or the first line of text. If a file fails only at the beginning, or if the first cue number looks wrong, save without a BOM and test again.

Special characters such as curly quotes, em dashes and musical notes are fine in UTF-8, but they depend on the font used by the player. A glyph that appears in your editor may fall back to a box on a television or an older phone. For maximum portability, use straight quotes and avoid symbols that carry meaning only in a specific font.

A complete SRT example

The example below is a complete, valid file. It has three cues, sequential numbers, comma-separated milliseconds and a blank line between cues. The text is deliberately plain so it can be copied into any player for a test.

Notice that the file ends after the last line of dialogue. A trailing blank line is tolerated by most parsers, but extra blank lines inside a cue can split it into two. If you paste the sample into a text editor, keep the spacing exactly as shown and save with a .srt extension.

1
00:00:00,500 --> 00:00:03,200
Welcome to the studio tour.

2
00:00:03,600 --> 00:00:06,900
We start in the control room.

3
00:00:07,400 --> 00:00:10,100
The mixer feeds four cameras.

Where SRT files are used

SRT is the default handoff format for a lot of video work. Editing software imports it, captioning agencies deliver it, and many upload forms accept it. YouTube Studio, for example, accepts subtitle files and lets creators download captions in SRT form. Adobe Premiere Pro, DaVinci Resolve, Final Cut Pro and CapCut all have caption or subtitle import paths that read SRT.

It is also common in places where a formal standard is less important than readability. A teacher can hand a student an SRT and a video file; the student can open both without a subscription. A researcher can store interview transcripts as SRT and search them as text. The same simplicity makes SRT a reasonable archive format: if the software disappears, the file is still readable.

The format is less suited to styled captions, karaoke timing and precise on-screen placement. Those jobs belong to WebVTT, ASS or a platform-specific caption format. SRT remains the interchange layer: easy to generate, easy to inspect and widely understood. That is also why a plain SRT survives a change of software: the words and times remain legible even when the original app is gone.

How to inspect an SRT before you send it

Before you send a file to a client or upload it to a platform, spend a minute on inspection. Open it in a plain text editor and check the first cue, the last cue and any cue with unusual characters. Then play the video with the subtitle file loaded and watch the opening minute at normal speed.

1. Confirm the extension is .srt, not .srt.txt.
2. Check that every cue has a number, an arrow timestamp and at least one line of text.
3. Look for comma separators in timestamps and a blank line between cues.
4. Verify that accented and non-Latin characters display correctly.
5. Run the file through the subtitle validator to catch overlaps and unreadable line lengths.

How to create an SRT with VoiceToTextFree

You can create an SRT by typing one, but the faster route is to transcribe the audio and let a tool draft the cues. VoiceToTextFree runs Whisper in the browser, so the audio stays on your device. Open the subtitle generator to upload a video or audio file, choose a model, and generate a transcript with timestamps. Then review the result before exporting.

Automated cues are a draft, not a final delivery. Names, numbers and overlapping speech often need correction. Use the SRT editor to adjust text and timing, then run the subtitle validator for line length and overlap warnings. The timing editor is useful when a whole block drifts a few seconds away from the speech.

• Transcribe with a model that fits your device and language.
• Correct names and punctuation before touching timing.
• Check reading speed, then export SRT.