Convert TXT to STL Online

How to Convert TXT to STL Subtitles Online

1. Upload Your TXT File: Drag and drop or click "+ Add Files" to load a plain-text subtitle script from your device. Batch upload is supported. Everything runs in your browser session — files never leave your machine.
2. Confirm STL as the Output Format: The output is fixed to STL (EBU Tech 3264 binary subtitle format). The converter parses your TXT for usable timecodes or sequential cue blocks and emits a compliant STL file with a 1024-byte GSI header followed by 128-byte TTI blocks.
3. Review Your TXT Layout (Recommended Before Upload): STL needs timed cues. If your TXT is a flat transcript with no timestamps, add cue numbers, HH:MM:SS:FF (or HH:MM:SS,mmm) start/end times, and blank lines between cues — the parser maps these into TTI records. Unstructured prose will still convert but every cue gets a placeholder duration.
4. Convert and Download: Click "Convert" and grab your .stl file individually or as a ZIP if you batched several. No sign-up, no watermark, no email gating.

Why Convert TXT to STL?

STL — the EBU Subtitling Data Exchange Format defined in EBU Tech 3264, first published February 1991 — is the file broadcasters and post houses still hand over when delivering subtitles to a TV channel or a tape-based archive. Plain-text scripts are how writers, translators, and transcriptionists work day-to-day. Converting TXT to STL is the bridge between an editorial deliverable and a broadcast deliverable.

• Broadcast delivery specs that demand STL — Many European public broadcasters (BBC, ARD/ZDF, France Télévisions, RAI) still require EBU STL alongside or instead of newer XML-based EBU-TT for legacy ingest pipelines. A translator's TXT script has to land as a compliant STL before it can be wrapped with the master video.
• Tape-era and MXF archive workflows — Archive systems built on tape masters or MXF carriers were designed around STL. Converting a corrected TXT transcript back into STL is the only way to refresh subtitle tracks on legacy material without re-mastering.
• DVD authoring and Blu-ray adjuncts — Some authoring suites still accept EBU STL as a subtitle import path, especially for European DVDs where Teletext-style subtitling was standard. Converting from a TXT script is faster than re-typing inside an authoring tool.
• Subtitle QA against an editorial source — If a vendor delivered an STL but your editorial team works in TXT, converting both directions lets you diff the two scripts to catch dropped lines, mis-spelled names, or off-by-one cue errors.
• Frame-accurate timing for PAL 25 fps and NTSC 30 fps — STL only supports 25 fps and 29.97 fps timecodes, so converting from TXT is also the point at which you commit to a frame-rate target — useful when your final video master frame rate is known.
• Localisation handoff — Translation memory tools export TXT; broadcast playout systems ingest STL. Converting in-browser keeps confidential pre-release scripts off third-party servers.

TXT vs STL — Format Comparison

Property	TXT (Plain Text)	STL (EBU Tech 3264)
Type	Human-readable plain text	Binary subtitle exchange format
Specified by	None (informal)	European Broadcasting Union, 1991
Timing	Optional, no required syntax	Mandatory; 25 fps or 29.97 fps timecodes
Structure	Free-form lines	1024-byte GSI header + sequence of 128-byte TTI blocks
Character set	UTF-8, ASCII, or any encoding	Latin (ISO 6937), Cyrillic, Greek, Arabic, Hebrew (declared in GSI)
Metadata carried	None	Language code, publisher, country, frame rate, max rows, max chars/row
Editable in	Any text editor	Subtitle Edit, EZTitles, FAB Subtitler, Spot, Cavena
Primary use	Scripts, transcripts, working drafts	Broadcast playout, DVD authoring, archive ingest
Best for	Drafting, translation, version control	Final TV/broadcast delivery

STL Frame Rate and Character Set Quick Guide

STL files begin with an 8-byte Code Page Number and a 3-byte Disk Format Code — the latter is the "STL25.01" or "STL30.01" string that identifies the timing base. Pick the wrong one and downstream tools refuse the file.

Disk Format Code	Frame rate	Used by	Notes
STL25.01	25 fps	PAL/SECAM (most of Europe, Australia, parts of Asia)	The historical default; BBC, EBU members
STL30.01	30 fps (29.97 drop-frame in practice)	NTSC (North America, Japan, parts of Latin America)	Less common; many tools assume 25 fps if not specified

For character sets, the GSI byte at offset 0 declares the Code Page Number (e.g., 850 for Latin-1, 437 for US-ASCII), and the byte at offset 3 declares the Character Code Table — 00 = ISO 6937-2 Latin, 01 = ISO 8859-5 Cyrillic, 02 = ISO 8859-6 Arabic, 03 = ISO 8859-7 Greek, 04 = ISO 8859-8 Hebrew. UTF-8 is not supported by the base spec, so non-Latin scripts that aren't in one of these tables (Chinese, Japanese, Thai, Devanagari) won't round-trip cleanly through classic STL — use EBU-TT or TTML instead.

Frequently Asked Questions

My TXT file has no timestamps — will the STL still work?

Technically yes, but every cue will share placeholder timing (usually 00:00:00:00 start with a default duration), which makes the STL unusable for playout. STL is a timed subtitle format; without HH:MM:SS:FF cues in the source, the converter cannot infer when each line should appear. Add timecodes to the TXT first — either manually or by running the transcript through a speech-aligned tool — then convert.

What time-code format should I use in my TXT file?

The cleanest input is the SRT-style block: an integer cue number on its own line, then HH:MM:SS,mmm --> HH:MM:SS,mmm on the next line, then one or two lines of subtitle text, then a blank line. The converter also recognises the EBU HH:MM:SS:FF (frames) syntax and will keep frame-accurate timing if the file declares 25 fps or 29.97 fps. Mixed formats in the same file produce unpredictable results.

STL only supports 25 fps and 29.97 fps — what if my video is 24 fps or 23.976 fps?

The EBU STL spec genuinely caps timing at 25 fps (STL25.01) or 29.97 fps (STL30.01). For cinema material at 24 fps or web at 23.976 fps, you have two choices: (1) round timecodes to the nearest STL25 frame and accept up to a ~40 ms drift per cue, or (2) deliver in EBU-TT, TTML, or SRT instead, which all support arbitrary frame rates. For most broadcast workflows the source is already conformed to 25/29.97, so this rarely bites in practice.

Why does my STL look garbled when opened in a text editor?

STL is binary, not text. The GSI block contains fixed-offset metadata fields (publisher, country code, language code, original program title) and each TTI block packs a cue number, timecode in BCD, justification code, vertical position, and the subtitle text bytes — none of which render as readable text. To inspect an STL, use a dedicated tool such as Subtitle Edit or the EBU STL viewer from Jongbel; opening it in Notepad shows mostly junk.

Will accented characters and non-Latin scripts survive the conversion?

Latin-1 (Western European) accented characters (é, ñ, ü, ç) round-trip cleanly via ISO 6937-2. Cyrillic, Greek, Arabic, and Hebrew work if you select the right Character Code Table in the GSI. Chinese, Japanese, Korean, Thai, Devanagari, and emoji are not supported by EBU STL — the spec predates Unicode adoption in broadcast workflows. For CJK or any script outside ISO 8859, use EBU-TT (XML, UTF-8) instead and re-deliver in that format if your downstream chain accepts it.

How many characters per line and how many lines per cue can STL hold?

The EBU STL spec defines a Maximum Number of Displayable Rows (MNR) and Maximum Number of Displayable Characters (MNC) in the GSI header. The conventional broadcast limits are 2 rows of 40 characters for Teletext-style subtitles (the BBC house style), though the format permits up to 23 rows and 40 characters per row. If your TXT lines exceed 40 chars they'll be wrapped or truncated by the player depending on the target system — keep cues under ~80 total characters across two lines.

Is the converted STL ready for direct ingest into a broadcast playout system?

Functionally yes — the file is bit-compliant with EBU Tech 3264. In practice, each broadcaster has their own house-style profile on top: required language codes, publisher fields, justification codes (centre vs left), and timing offsets relative to programme start. Open the STL in a broadcast-grade tool (EZTitles, FAB Subtitler, WinCAPS) to set those fields before final delivery — the converter fills in sensible defaults but won't know your channel's exact spec.

What's the difference between EBU STL and EBU-TT? Should I use STL at all in 2026?

EBU STL (Tech 3264, 1991) is the legacy binary format. EBU-TT (Tech 3350, 2012) is its XML/UTF-8 successor based on W3C TTML, and the EBU now recommends EBU-TT for new workflows. STL persists because tape archives, older playout servers, and DVD authoring chains still expect it — and many delivery specifications continue to list STL as an acceptable format alongside EBU-TT. If your downstream chain accepts EBU-TT, prefer it. If the spec sheet says "EBU STL" or the ingest system is older than ~2015, convert to STL.

Is anything uploaded to your servers during conversion?

No. The TXT-to-STL conversion runs entirely in your browser via in-page JavaScript — your script never leaves the tab. There is no sign-up, no watermark, and no file size limit imposed by us. This matters for pre-release content under embargo or NDA, where script files cannot legally be sent to third-party servers.