Caption Format Reference
EBU-STL File Format (.stl)
EBU-STL is the European counterpart to SCC: a binary, frame-based broadcast deliverable that has outlasted the technology it was designed for. Its two defining constraints — a fixed frame rate and a single character table per file — are the source of almost every conversion problem.
What can an EBU-STL file be converted to?
EBU-STL converts to SRT, WebVTT, TTML, IMSC, PAC and EBU-TT with its text and timing intact. Converting to SCC or MCC additionally requires a frame rate conform, because STL runs at 25 fps and SCC runs at 29.97 fps. Non-Latin content cannot convert to SCC at all.
EBU-STL at a glance
STL is a binary format with a fixed block structure: a header describing the file as a whole, then one fixed-size block per subtitle. That rigidity is why it is reliable in a machine room and awkward everywhere else.
| Property | Value |
|---|---|
| Full name | EBU Subtitling Data Exchange Format |
| Extension | .stl |
| Specification | EBU Tech 3264 |
| File structure | Binary. A General Subtitle Information header block, then one Text and Timing Information block per subtitle |
| Frame rate | 25 or 30 fps, declared in the header |
| Timing model | Explicit in and out timecode on every subtitle |
| Character support | One script per file, selected by the Character Code Table field |
| Positioning | Teletext row number, with horizontal justification |
| Styling | Teletext colours, set by control codes inside the text |
| Display standard | Open subtitles, or teletext level 1 or level 2 |
| Metadata | Programme title, episode, translator and reel information in the header |
| Closed Caption Creator | Read and write |
For the header fields, teletext control codes and delivery rules in full, see EBU-STL and teletext subtitles.
What EBU-STL can and cannot carry
STL carries more presentation data than SRT and less than TTML. The limits that matter in practice are the single character table and the fixed frame rate, both of which are file-level settings rather than per-subtitle ones.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | One script per file |
| Explicit in and out times | Yes | Both timecodes are stored per subtitle |
| Row positioning | Yes | Vertical position as a teletext row number |
| Horizontal justification | Yes | Left, centred or right |
| Teletext colours | Yes | Set by control codes embedded in the text field |
| Italics | Yes | How emphasis renders depends on the display standard in use |
| Non-Latin scripts | Yes | Cyrillic, Greek, Arabic and Hebrew are available through the character table |
| Mixed scripts in one file | No | The character table is a single file-level setting |
| Frame rates other than 25 or 30 | No | Material at 23.976 or 29.97 fps must be conformed |
| Two languages in one file | No | The header carries a single language code |
| Fonts and text size | No | Appearance is decided by the teletext decoder or the burn-in engine |
| Programme metadata | Yes | Title, episode, translator and reel fields in the header |
Who asks for EBU-STL files?
STL is what European broadcast asks for, and it remains the accepted interchange format between subtitling houses and playout even where teletext itself has been retired.
- European broadcasters and EBU member organisations, as a playout deliverable.
- Teletext and DVB subtitle insertion systems.
- Subtitling and localisation houses exchanging work between tools.
- Archive and library material, where STL is often the only surviving subtitle asset.
- Post houses conforming an international edit to a European delivery specification.
If the delivery is North American broadcast, the equivalent is SCC or MCC. If it is a modern European OTT delivery, the spec has probably moved to EBU-TT-D or IMSC.
How do I open an EBU-STL file?
STL is binary, so a text editor is not much use. Open one and you will see a partially readable header — the programme title and translator name are stored as plain characters — followed by unreadable fixed-length blocks.
Reading the subtitles requires a tool that understands the block structure and, critically, applies the correct character table. The same bytes decode to different text depending on which script the file declares.
Never edit an STL in a hex editor to fix a typo. The blocks are fixed length and the header carries counts that must agree with the body; changing one without the other produces a file that opens but fails validation downstream.
Converting EBU-STL to another format
Converting out of STL is mostly straightforward, with two exceptions: anything targeting 29.97 fps needs a genuine conform, and anything non-Latin needs a target that can represent the script.
| Convert EBU-STL to | What survives | What to watch for |
|---|---|---|
| TTML / IMSC | Text, positioning, colour | The closest match in capability. Rows map to regions and teletext colours map to style attributes. |
| SRT | Text and line breaks | Colours, row positions and justification are all discarded. Frame timing converts to milliseconds. |
| WebVTT | Text, approximate positioning, colour | Rows become percentages of the frame and colours become CSS classes the player may not render. |
| SCC | Text and colour | A 25 to 29.97 fps conform is mandatory. Only seven colours are available, and non-Latin content cannot convert at all. |
| MCC | Text, colour, placement | As SCC, except MCC can target 25 fps directly, which avoids the conform entirely. |
| PAC | Text, colour, placement | The closest sibling format. Both are row-positioned and code-page based; confirm the target code page matches the script. |
| EBU-TT / EBU-TT-D | Text, positioning, colour | The modern XML successor. The mapping is well defined, but the delivery spec decides which profile applies. |
| Burnt-in video | Text and placement | Teletext rows become pixel positions, and font, size and outline all become new decisions. |
Converting another format to EBU-STL
Converting into STL means committing to two file-level choices the source format probably did not make for you: a frame rate and a character table. Both are set once and apply to every subtitle in the file.
| Convert to EBU-STL from | What carries over | What the conversion has to decide |
|---|---|---|
| SRT | Text and line breaks | Row placement, justification, a 25 fps timing base, and a character table for the language. |
| WebVTT | Text and approximate placement | Percentage cue settings snap to teletext rows, and CSS colours reduce to the teletext palette. |
| TTML / IMSC | Text, placement, colour | Which region becomes which row, and what to do with font and size styling STL cannot express. |
| SCC | Text and colour | A 29.97 to 25 fps conform, and a mapping from the 608 character grid onto teletext rows. |
| MCC | Text, colour, placement | Which caption service to read, then the same conform as SCC unless the MCC is already 25 fps. |
| PAC | Text, colour, placement | Code page to character table mapping. Get this wrong and non-Latin text is destroyed rather than degraded. |
| Transcript (DOCX, TXT, CSV) | Text | Everything else. A transcript has no timing, placement or colour to carry over. |
Closed Caption Creator reads and writes every format in both tables. See the full file format support list, or the conversion API and CLI for batch workflows.
Where EBU-STL conversions go wrong
STL fails quietly. A file with the wrong header settings opens without complaint and is wrong all the way through.
- A relabelled frame rate. The header declares 25 or 30 fps. Changing that field without re-timing the subtitles does not conform the file — it just makes the drift harder to diagnose.
- The wrong character table. One setting governs the entire file. Deliver Cyrillic content declared as Latin and the text is not degraded, it is unrecoverable at the far end.
- Confusing EBU-STL with Spruce STL. Two unrelated formats share the
.stlextension. A tool expecting one will reject or misread the other. - Teletext control codes consuming line length. Colour changes occupy character cells on a teletext line, so a line that fits in your editor can overflow on air.
The teletext line-length behaviour is covered in detail in EBU-STL and teletext subtitles. For cross-format delivery checks, see how to QC closed captioning and subtitles.
EBU-STL conversion questions
Common questions about moving subtitles into and out of the EBU-STL format.
They are unrelated formats that share an extension. EBU-STL is binary, so opening it in a text editor shows mostly unreadable bytes with a few readable header fields such as the programme title. Spruce STL is plain text and immediately readable, with lines containing timecodes and subtitle text. If the file is readable, it is not EBU-STL.
Only with a frame rate conform. STL runs at 25 fps and SCC exists only at 29.97 fps, so every subtitle has to be re-timed rather than relabelled. There is a second constraint: SCC carries no Cyrillic, Greek, Arabic or Hebrew, so only Latin-script STL content can make the trip.
They are discarded. SRT has no colour field, and the <font> tag convention is honoured inconsistently across players. If colour is carrying meaning — speaker identification in particular — convert to WebVTT, TTML or IMSC instead, or move the speaker information into the text itself before converting.
Approximately. STL positions subtitles on numbered teletext rows and WebVTT positions cues as percentages of the video frame, so a converter maps between the two models. Subtitles land in roughly the right place, but a caption deliberately raised to clear a lower third should be checked against picture rather than assumed.
Almost always because the frame rate was changed rather than conformed. Editing the header field relabels the file without moving any subtitle, so the timings stay where they were and slip progressively against picture. A real conform recalculates every in and out timecode against the new rate.
Decide first whether the picture was slowed or re-conformed, because that determines whether the subtitles need a speed change or a straight offset. A 25 to 23.976 fps pulldown scales every timecode; a re-conformed edit needs the subtitles re-timed against the new master. Applying the wrong one produces a file that starts in sync and ends badly out.
Conform and convert STL without guesswork
Closed Caption Creator reads EBU-STL with the correct character table, previews teletext spacing against picture, and writes a valid file back out with the header fields intact.
Conform between 25 and 29.97 fps properly, and QC line length and reading speed before the file reaches playout.