Subtitle File Formats Explained

What a subtitle file actually is

A subtitle file is a text document that pairs pieces of text with the times at which they should appear and disappear. Nothing about the video is stored in it. The player reads the file, watches the playback clock, and draws each piece of text when its time arrives. Because the file is just text plus timing, you can usually open it in an ordinary text editor and read it.

Each piece of text with its start and end time is a subtitle cue. Formats differ mainly in three things: how they write the timing, how much extra information they can carry (position, color, fonts, language labels), and which software is willing to read them.

The plain-text family

The simplest and most widely supported kind is usually called SRT, after the program it originally came from. Each entry has a running number, a line with a start time and an end time, and then one or two lines of text, followed by a blank line. A single entry looks like this:

1
00:00:01,000 --> 00:00:03,500
Where did you leave the keys?

The cue appears at one second and disappears at three and a half seconds, so it stays on screen for 2.5 seconds. Note the comma before the milliseconds, which is a quirk of this format. These subtitle timecodes are written as hours, minutes, seconds and milliseconds rather than as frame counts.

The appeal is simplicity. Almost every player, editor and platform can read it, and a person can fix a typo by hand. The limit is the same thing: the format has no official way to say where a cue sits on the screen or what color it should be. Some tools tack on informal tags such as italics, but support varies from player to player.

The web-oriented format

WebVTT looks similar to the plain-text format but is designed for web video. The file starts with a header line, the timing uses a period rather than a comma before the milliseconds, and the running number is optional. It adds cue settings, which can place a cue near the top of the frame or align it left or right, and it supports basic styling through style rules like those used on web pages. It can also mark up the speaker or a language change inside a cue.

Because browsers understand it directly, it is a common choice when a page needs to show text over a video. Players built on the web usually accept it even when they refuse other files, which is covered in more detail in the discussion of how pages deliver subtitle text.

XML-based formats

A third family stores subtitles as structured XML. TTML is the best-known example, and several broadcast and streaming workflows use profiles of it. These files are longer and harder to read by eye, but they can describe regions of the screen, fonts, colors, background boxes and timing in considerable detail. They suit professional delivery, where a single master file may be converted into several other formats later.

The trade-off is compatibility. A consumer player may ignore much of the styling or fail to open the file at all, and different delivery systems often accept only a particular profile. If you receive one of these files, check what the receiving system actually expects before sending it on.

Formats made for editing and for specific industries

Some formats exist mainly because a particular tool or industry needed them:

• Advanced styling formats originally associated with fansubbing and anime communities (ASS is the common name) can carry fonts, outlines, motion and precise placement. Support is good in some desktop players and weak elsewhere.
• Broadcast exchange files used by television workflows are often binary rather than plain text, and they may impose limits on characters per line and on the character set.
• Disc and cinema formats may store subtitles as images rather than text. An image-based subtitle is a picture of the words, so it cannot be searched, resized cleanly or edited like text, though it preserves exact appearance.
• Project files from editing programs hold subtitle work in progress. They are not meant for delivery and generally need exporting.

If you meet a format you do not recognize, look at the extension and open the file in a text editor. Readable lines with times are a good sign that you are looking at a text-based format.

What formats can and cannot store

Most formats can store the words, the start and end times, and line breaks. Beyond that, support is uneven:

• Positioning and alignment: supported in the web and XML families, rarely in plain text.
• Color, fonts and backgrounds: supported by richer formats, discussed in the piece on styling information in subtitle files.
• Language labels: usually carried by the file name or by the surrounding container, not always inside the file itself.
• Speaker names and non-speech information: these are normally just typed into the text, for example a sound description in square brackets, rather than stored as special data.
• Frame rate: some formats count in frames, which makes frame rates matter. Time-based formats are less sensitive, though they can still drift if the video has been re-timed.

A subtle point is that captions versus subtitles is a content question, not a file question. The same format can hold either, and the file does not say which one it is.

Choosing a format

A few questions usually narrow the choice quickly:

1. Where will the file be shown? Check the requirements of the platform, player or broadcaster first. They often decide the matter.
2. How much styling do you need? If you need nothing beyond words and timing, the plain-text format is the safest. If cues must move around the screen, choose a format that supports placement.
3. Do you need to keep a master? Many teams keep one detailed master and export simpler files from it. Exporting downward loses information, so converting back up does not restore it.
4. Which languages are involved? Check that the format and the player handle your scripts, including right-to-left scripts, and see the separate discussion of character encoding.

Conversion and housekeeping

Converting between text-based formats is usually straightforward, but conversions can quietly drop styling, change how line breaks work or alter timing at the millisecond level. After any conversion, play the result in the actual target player and run through a quality checklist rather than assuming it matches the original. Keep clear file names and use version control or at least dated copies, so that you always know which file is the approved one.

No format guarantees identical appearance everywhere. Players apply their own defaults and viewers can change their own settings, so treat a file as a set of instructions that each player interprets in its own way.