Turn STL subtitle files into TTML for modern players and workflows—fast, simple, and processed directly in your browser.
Two unrelated subtitle formats are both called "STL", and this page reads only one of them: the plain-text Spruce / DVD Studio Pro cue list. TTML is the XML format the W3C standardised for timed text, and it is the base for the EBU's own broadcast successor, EBU-TT. Converting a Spruce cue list to TTML is the practical way to get flat timecoded text into an XML toolchain. This page is a reference for what each format holds and exactly what this converter transfers between them.
The conversion runs entirely in your browser.
Spruce / DVD Studio Pro STL (text) — supported. Cue lines are shaped 00:00:04:12 , 00:00:07:19 , First row|Second row, where | separates rows within a cue. Header directives like $TapeOffset = FALSE and // comments are skipped without complaint. If you can read the file in a text editor, this is what you have.
EBU Tech 3264 STL (binary) — not supported. The format broadcasters mean by "EBU STL" is a binary file: the EBU's Specification of the EBU Subtitling data exchange format, published 27 February 1991, defines one 1024-byte General Subtitle Information block followed by 128-byte Text and Timing Information blocks. Those blocks are where teletext colour, the Vertical Position row number and the Justification Code live — none of which exists in a Spruce file. A Tech 3264 file is a run of fixed-width binary records rather than lines of text, so it yields zero cues here and the page reports "No cues parsed from input. Check the format." If a text editor shows a short readable programme title and then mojibake, that is the flavour you have, and you need a Tech 3264-aware tool such as Subtitle Edit first. For a standards-grade migration the EBU publishes Mapping EBU STL to EBU-TT Subtitle Files (Tech 3360, 24 May 2017), which specifies how each Tech 3264 field should become EBU-TT XML.
| Property | Value |
|---|---|
| Associated with | Spruce DVD authoring tools and Apple DVD Studio Pro |
| Serialization | Plain text, one cue per line |
| Cue syntax | hh:mm:ss:ff , hh:mm:ss:ff , text |
| Timing basis | Timecode with a trailing frame field |
| Frame rate | Not recorded in the file; this page assumes 25 fps unconditionally |
| Line break in a cue | | |
| Inline styling | ^B bold, ^I italic, ^U underline — passed through as literal text, not interpreted |
| Header directives | $Keyword = Value lines, skipped |
| Comments | // lines, skipped |
| Colour and positioning | Not expressible in the format at all |
| Extension clashes | Shares .stl with binary EBU Tech 3264 and with stereolithography 3D models |
| Property | Value |
|---|---|
| Standard | W3C Timed Text Markup Language 1 (TTML1), Third Edition |
| Status | W3C Recommendation, 8 November 2018 (edited in place 20 August 2020) |
| Serialization | XML |
| Root element | tt, in namespace http://www.w3.org/ns/ttml |
| Media type | application/ttml+xml |
| Timing | begin and end attributes on <p>, written here as HH:MM:SS.mmm clock time |
| Line breaks | <br/> inside the <p> element |
| DFXP | Distribution Format Exchange Profile — a profile name retained for historical reasons |
| Broadcast derivatives | EBU-TT Part 1 (Tech 3350 v1.2, May 2017), SMPTE-TT, IMSC |
| Best for | Archiving, interchange and OTT caption delivery |
The output is deliberately minimal: an XML declaration, a tt root carrying the TTML namespace, then a single body and div holding one <p> per cue with begin and end clock times and <br/> for row breaks. There is no head, no styling section, no layout section, and no xml:lang attribute on the root. TTML1's own examples carry xml:lang on tt, and stricter broadcast profiles expect a real language tag there, so add one if your validator or downstream tool asks for it.
Two things are worth knowing before you put the output into a pipeline. First, cue text is inserted into the XML without escaping, so a cue containing & or < — think "R&B", "AT&T", "Tom & Jerry" — produces a document that is not well-formed XML and will be rejected by any conforming parser. Check the output for those characters and replace them with & and < before shipping. Second, frame fields are converted at a fixed 25 fps with no control to change it, so a 30 fps STL, which Tech 3264 explicitly permits, will be mistimed; frame fields of 25 and above are handled incorrectly and can even move a cue backwards.
In our testing against this page's own emitter, the TTML and DFXP outputs are byte-identical apart from one extra namespace declaration — DFXP adds xmlns:tts="http://www.w3.org/ns/ttml#styling" to the root and nothing else, because no styling attributes are actually emitted.
No. It handles only the Spruce / DVD Studio Pro text flavour of .stl. A conformant Tech 3264 file is binary — a 1024-byte GSI block followed by 128-byte TTI blocks — and produces zero cues here, with the message "No cues parsed from input. Check the format."
Not quite. DFXP stands for Distribution Format Exchange Profile, a profile of TTML that the W3C keeps as a name for historical reasons; people often use "DFXP" loosely to mean a TTML file, and the .dfxp extension is common in captioning workflows. From this converter the two outputs differ by a single namespace declaration on the root element, so if a tool insists on .dfxp, use STL to DFXP or simply rename the file.
No. Colour, the Vertical Position field that sets the teletext row, and the Justification Code that sets alignment all live in the binary TTI block, and the text flavour this tool reads does not carry them. TTML can express positioning and colour through region and tts: styling attributes, but the output here contains cue text and timing only — nothing is invented to populate those fields.
Almost certainly an unescaped & or < in the subtitle text. The emitter writes cue text straight into the <p> element without escaping, and both characters are reserved in XML, so a single "Tom & Jerry" makes the whole document non-well-formed. Search the output for bare & and < and replace them with & and <.
A fixed 25 fps, with no frame-rate control on the page. That matches the STL25.01 Disk Format Code but not STL30.01, the 30 fps variant Tech 3264 also defines. On 30 fps or 29.97 fps material the timings will not be right, and any frame field of 25 or above is converted incorrectly.
No. EBU-TT is a constrained profile of TTML defined in EBU Tech 3350 (Part 1, version 1.2, May 2017) as an XML archiving and interchange format for broadcast subtitles. It requires structures and metadata this minimal output does not include. If you need genuine EBU-TT rather than generic TTML, treat this output as a starting point and follow Tech 3360's mapping guidance.
Millisecond precision, written as HH:MM:SS.mmm. Because one frame at the assumed 25 fps is exactly 40 ms, frame boundaries land on exact millisecond values with no rounding: a cue at 00:00:04:12 becomes begin="00:00:04.480".
No. This page is client-side. The file is read by the browser's own file reader, parsed by JavaScript in the page, and the download is generated locally.
Yes, though not on this page. TTML to SRT parses <p> elements with begin and end attributes and writes standard SRT cues. Be aware that a round trip carries text and timing only — anything you add to the TTML by hand, such as regions or styling, is dropped on the way back out.