A Field Guide to Subtitle and Caption Formats Beyond SRT and VTT

Why there are so many subtitle formats

Every subtitle file answers the same two questions: what text appears, and when. The formats multiplied because different industries needed different extras. Broadcasters needed captions that fit inside a television signal and obeyed its character limits. Disc authors stored pictures instead of text so subtitles looked identical everywhere. Fansubbers wanted karaoke and typesetting. Streaming services wanted XML they could validate automatically.

The result is a family of formats that overlap in their core and diverge at the edges. A quick map:

SRT and WebVTT

Plain text cues with start and end times. The everyday pair for players and web platforms

SSA and ASS

Text with named styles, override tags, exact positions and karaoke timing

TTML family

XML timed text: DFXP, IMSC, EBU-TT and SMPTE-TT are profiles or close relatives

SCC

Encoded CEA-608 caption data with SMPTE timecode, used to author broadcast-style captions

EBU STL

A binary exchange format from European broadcasting, built around teletext constraints

SBV, SubViewer, MicroDVD

Simple text formats; MicroDVD counts frames rather than time

PGS and VobSub

Bitmap subtitles from Blu-ray and DVD, stored as images rather than text

How SRT and VTT compare with each other is a separate question with its own pages; here they serve as the baseline. For hand edits, see the guide to editing an SRT file.

SSA and ASS: styled text for typesetting and karaoke

SubStation Alpha (SSA) and its successor Advanced SubStation Alpha (ASS) are plain text files divided into sections. A script info section sets the resolution the subtitles were designed for. A styles section defines named styles: font, size, primary and outline colours, bold and italic, alignment, margins, border and shadow. An events section then lists each line with its start time, end time, style name and text.

The power is in override tags, short commands in curly braces placed inside the text. They can switch italics on for one word, move a line to an exact coordinate, rotate or fade it, change colour mid-line or time each syllable for karaoke. ASS timestamps are written to the hundredth of a second, slightly coarser than the millisecond precision of SRT and VTT.

ASS is the native format of editors such as Aegisub and is widely used for anime fansubs and for subtitles embedded in MKV files, where players render it with libraries such as libass. Its weakness is portability: most web players, social platforms and TV apps ignore the styling or reject the file outright.

TTML, DFXP and IMSC: XML timed text for delivery

Timed Text Markup Language (TTML) is a W3C standard that describes subtitles in XML. Each paragraph element carries begin and end attributes, and separate styling and layout sections define fonts, colours and regions of the screen where text may appear. Because it is XML, a TTML file can be checked against a schema before delivery, which is one reason distributors like it.

The names around it cause confusion. DFXP was the name of the original TTML 1.0 distribution profile, and many tools still label TTML files as DFXP. IMSC (Internet Media Subtitles and Captions) is a W3C set of TTML profiles aimed at streaming, with a text profile and an image profile. EBU-TT is the European Broadcasting Union's TTML profile, and SMPTE-TT is a TTML-based format from SMPTE that can also carry legacy caption data.

Many streaming and broadcast delivery specifications ask for IMSC or another TTML profile, but each one sets its own rules about frame rates, regions and allowed styling. Two files can both be valid TTML and still fail a particular platform's check, so always read the current delivery spec rather than assuming any TTML will do.

SCC and EBU STL: broadcast caption files

SCC (Scenarist Closed Caption) looks like text but is really a list of SMPTE timecodes, each followed by hexadecimal byte pairs. Those bytes are CEA-608 caption commands and characters, the same data that travels inside a North American television signal. An SCC file therefore inherits 608's limits: a restricted character set, a grid of roughly 32 characters per row, and display modes such as pop-on, roll-up and paint-on. It is still requested by some broadcasters and online platforms as a way to deliver captions authored to broadcast rules. The broadcast standards themselves are explained in CEA-608 vs 708.

EBU STL, defined in EBU Tech 3264, is a binary file made of a general information header followed by fixed-size blocks, one per subtitle. It was designed for exchanging teletext-style subtitles between European broadcasters, so row lengths, code pages and timecode follow broadcast conventions. You cannot open it meaningfully in a text editor.

Beware of a name clash: Spruce STL, used by some DVD authoring tools, is an unrelated plain text format that happens to share the extension. If a tool rejects an .stl file, check which of the two you have.

Simple formats: SBV, SubViewer, MicroDVD and embedded MP4 text

SBV is the plain format YouTube has used for subtitle downloads. Each cue is a line with start and end times separated by a comma, followed by the text and a blank line. It is close to SRT minus the cue numbers, and conversion between the two is usually lossless for the text and timing.

SubViewer files are similarly simple. MicroDVD .sub files are different in one important way: they store start and end frame numbers instead of times. The same file shows subtitles at different moments depending on the frame rate the player assumes, which is why MicroDVD subtitles often drift when used with a different encode of the same film.

MP4 files can also carry a subtitle track internally, usually in the 3GPP timed text format (often listed by tools as mov_text), which players show unevenly.

Image-based subtitles: PGS and VobSub

DVD subtitles (VobSub, an .idx index plus a .sub data file) and Blu-ray subtitles (PGS, usually .sup) store each subtitle as a small picture with a display time. They look exactly as the author intended on any compliant player, and they can show any script because nothing has to be rendered from a font.

The trade-off is that there is no text inside. You cannot search them, correct a typo or translate them without first running optical character recognition, which needs checking afterwards, especially for italics, accented letters and non-Latin scripts.

What a conversion keeps and what it drops

When you convert between formats, the words and the start and end times almost always survive. Everything else depends on whether the target format has somewhere to put it:

• Styles and fonts from ASS or TTML disappear when converting to SRT, SBV or SCC.
• Exact positions are lost or approximated; WebVTT cue settings can keep some placement, SRT has no reliable way to store it.
• Karaoke and animation tags from ASS have no equivalent outside ASS.
• Frame-based timing (MicroDVD, broadcast timecode) must be converted to clock time using the correct frame rate, and rounding can shift cues by a frame.
• Characters outside the target's character set are replaced or dropped, which matters for SCC and older STL code pages.
• Long lines may break 608 or teletext row limits and need re-segmenting by hand.
• Image-based subtitles need OCR before they can become text at all.

Converting upwards, from SRT to ASS or TTML, gains nothing automatically. The tool wraps your plain cues in a default style, and any positioning or styling still has to be added by a person.

How to convert a subtitle file safely

1. Identify the format from the content, not just the extension: open it in a text editor and look for XML tags, hexadecimal pairs, a styles section or unreadable binary.
2. Keep the original file untouched and convert a copy.
3. Use a dedicated subtitle editor such as Subtitle Edit or Aegisub, or ffmpeg for simple text-to-text conversions, rather than renaming the file.
4. Set the frame rate explicitly whenever either side uses frames or timecode.
5. Re-check line length and segmentation against the target's rules after conversion.
6. Play the converted file against the video, checking the first, middle and last cues for timing.
7. Validate against the recipient's own checker or spec where one exists.

Common mistakes and the limits of conversion

• Renaming a file to change its format. The bytes stay the same, and the receiving tool either rejects it or misreads it.
• Assuming every TTML or DFXP file is interchangeable. Profiles and platform specs differ.
• Converting with the wrong frame rate, so every cue drifts further out of sync as the video goes on.
• Expecting styling to come back after a round trip through SRT. Once dropped, it is gone.
• Ignoring encoding. A file saved in a legacy code page shows garbled accents in another tool; the article on subtitles showing strange characters explains how to re-save as UTF-8.
• Trusting OCR output from image subtitles without proofreading it.

Where mydubly's SRT and VTT files fit

mydubly exports subtitles as SRT and VTT only, both UTF-8 with a byte order mark. Each job produces one subtitle track, in the spoken language or the target language, with one numbered, single-line cue per recognized speech segment. The files contain no styling, positioning, italics, sound tags or speaker labels, so there is nothing to lose when you convert them to a richer format.

If a platform or client needs ASS, TTML, SCC or STL, generate the SRT with the mydubly subtitle generator, review it, then convert it in a subtitle editor and apply the target's style and line rules there. mydubly cannot import subtitle files of any format, so it cannot convert existing files for you or re-time a file you already have. The translated video it produces also contains no subtitle track; subtitles always arrive as separate files.

Next step: match the file to the destination

Before converting anything, find out exactly what the destination accepts and under what rules, then work from the simplest clean source you have. For most web players and platforms, that source is a reviewed SRT or VTT. The SRT generator page shows what mydubly's files look like, and a 10-minute test file costs 10 credits (1¢).