Convert STL to VTT Online

Converting STL Subtitles to WebVTT: What This Page Covers

WebVTT is the format an HTML5 <video> element loads through a <track> element, so most people converting .stl are trying to get broadcast-era captions onto a web player. This page walks through that conversion, tells you which of the two very different formats that share the .stl extension this tool actually reads, and is explicit about what gets dropped along the way.

The conversion runs in your browser. The file is read by the browser's own file reader, parsed by page JavaScript, and handed back as a download.

How to Convert STL to VTT

1. Load Your STL Cues: Click *� Upload .stl to pick a file, or paste the cue lines directly into the Input (STL) box — the character counter beside the label confirms the text registered. The picker takes one file at a time.
2. Confirm the Format Selects: From format should read STL and To format should read VTT. Both are preset from the page URL, and the same two dropdowns retarget the conversion to any of the 13 supported subtitle formats without a reload.
3. Run the Conversion: Click Convert →. Parsed cues appear in the Output (VTT) pane with its own character count. If that pane stays empty and you get "No cues parsed from input", read the flavour section below — it is almost always the cause.
4. Save the Track: Use ⬇ Download .vtt to save the file, or *� Copy to paste the track straight into a build step or a CMS field. No sign-up, no watermark.

Which .stl File Do You Actually Have?

Two unrelated formats claim the .stl extension, and this converter reads only one of them.

Spruce / DVD Studio Pro STL (text) — supported. Cue lines look like 00:00:04:12 , 00:00:07:19 , First row|Second row: an in and out timecode in hh:mm:ss:ff form, comma-separated, with | marking a line break inside the cue. Header directives such as $TapeOffset = FALSE and // comment lines are skipped harmlessly. Open the file in any text editor — if you can read it, this is what you have, and it will convert.

EBU Tech 3264 STL (binary) — not supported. The EBU's Specification of the EBU Subtitling data exchange format, published 27 February 1991, defines a binary file: one 1024-byte General Subtitle Information (GSI) block followed by a run of 128-byte Text and Timing Information (TTI) blocks. Opening one in a text editor shows a short readable header — the programme title, and a Disk Format Code reading STL25.01 or STL30.01 — then mojibake. Feeding it to this page produces zero cues and the "No cues parsed from input" message, because the binary block structure does not match the text cue pattern at all.

How STL Cue Fields Map to WebVTT

Spruce STL	WebVTT	Notes
00:00:04:12 in-timecode	00:00:04.480 cue start	Frames are converted at a fixed 25 fps: 12 frames = 480 ms
00:00:07:19 out-timecode	00:00:07.760 cue end	Same fixed 25 fps assumption
, field separator	-->	Surrounding whitespace is tolerated on input
| inside cue text	real line break	Becomes a second physical line in the cue payload
(none)	WEBVTT first line	Required signature, written for you
(none)	cue numbers 1, 2, 3	Optional in WebVTT; emitted anyway
$TapeOffset, // lines	dropped	Header directives carry no cue data
^B / ^I / ^U style codes	passed through as literal text	Not interpreted and not stripped — see below

In our testing against this page's own parser, a cue timed 00:00:04:12 , 00:00:07:19 came out as 00:00:04.480 --> 00:00:07.760, which is exact: at the assumed 25 fps one frame is 40 ms, so 12 frames is 480 ms and 19 frames is 760 ms.

What Carries Over, and What Was Never There

Feature	In your Spruce .stl	In the VTT output
Cue text	yes	preserved
Line breaks (|)	yes	preserved as real line breaks
Start and end times	yes, to the frame	preserved to the millisecond
^B / ^I / ^U inline styling	yes	left in the text verbatim, not converted
Colour	no	—
On-screen positioning	no	—
Text alignment	no	—
Font and size	no	—

Nothing is actually lost in the bottom four rows, because a Spruce cue line has nowhere to record any of it — it is two timecodes and a string. This is worth spelling out because the teletext colour and row positioning people associate with the name "EBU STL" belong to the binary Tech 3264 format, which this page does not read. If your captions ever had those attributes, they were already gone by the time the file reached you as text. WebVTT could express position and colour through cue settings and a STYLE block, but nothing here is invented to fill those fields.

Common Errors and How to Fix Them

• "No cues parsed from input. Check the format." — Nearly always a binary EBU Tech 3264 file rather than a Spruce text file. Open it in a text editor; if it is unreadable, run it through a tool that speaks binary STL first — Subtitle Edit is the usual free choice, and its Ebu.cs implements the 1024-byte GSI and 128-byte TTI blocks directly — then export SRT and come back.
• Carets or letters like ^I showing up on screen — Those are Spruce inline style codes for italic, bold and underline. They are copied through as ordinary characters. Delete them in the Input (STL) box before converting, or strip them from the output.
• Every cue drifts progressively later or earlier — Your source is 30 fps or 29.97 fps material. The parser converts the frame field at a fixed 25 fps and there is no frame-rate control on the page, so a 30 fps file is mistimed.
• Cues after a certain point jump backwards in time — The same 30 fps problem in its ugly form. Frame fields of 25 and above are not handled correctly, so a cue at 00:00:01:29 can land earlier than one at 00:00:01:12. If your file uses frame numbers above 24 anywhere, do not trust the output.
• A & or a < in the text behaves oddly in the player — WebVTT reserves < to open a cue span tag and & to open a character reference. The converter passes both through unescaped, so <5 euros can be swallowed by the browser's parser. Replace them with < and & in the output.
• The browser ignores the file entirely — A <track> element needs the file served with the text/vtt media type and, if it is on another origin, with CORS headers. That is a serving problem, not a conversion problem.

When This Doesn't Work

If your .stl is binary EBU Tech 3264, if it is 30 fps, or if the teletext colour and row positions are part of what you are being paid to preserve, this page is the wrong tool and no amount of retrying will change that. Broadcast-grade STL work wants a converter built on the EBU's own Mapping EBU STL to EBU-TT Subtitle Files guidance, which defines how Tech 3264 fields become modern XML. For a quick text-only rescue, STL to SRT produces the same cue timings in the format most players and editors accept, and SRT to VTT will take that result the rest of the way to a web-ready track.

Frequently Asked Questions

Does this page read binary EBU Tech 3264 STL files?

No. It reads the Spruce / DVD Studio Pro text flavour of .stl only — cue lines of the form hh:mm:ss:ff , hh:mm:ss:ff , text. A genuine Tech 3264 file is binary, built from a 1024-byte GSI block and 128-byte TTI blocks, and produces zero cues here along with the message "No cues parsed from input. Check the format."

What frame rate does the converter assume for the STL frame field?

25 fps, unconditionally, with no control to change it. EBU Tech 3264 itself allows exactly two rates, signalled by the Disk Format Code: STL25.01 for 25 fps and STL30.01 for 30 fps. If your material is the 30 fps variant, or NTSC 29.97, the output timings will be wrong.

Will teletext colours and subtitle positioning survive the conversion to VTT?

No. Colour, the Vertical Position field that sets the teletext row, and the Justification Code that sets left/centre/right alignment all live in the binary TTI block and are absent from the text flavour this tool reads. The output is plain WebVTT cues with default positioning; WebVTT could express those things through cue settings and a STYLE block, but nothing here fabricates them.

Is my subtitle file uploaded to a server when I use this page?

No. This converter is client-side: the file is read locally with the browser's file reader, parsed by JavaScript running in the page, and returned as a download generated in the browser.

How precise are the timings in the WebVTT output?

To the millisecond. WebVTT timestamps are HH:MM:SS.fff, and because one frame at 25 fps is exactly 40 ms, every frame boundary in a 25 fps source lands on an exact millisecond value — frame 12 becomes .480, frame 19 becomes .760. No rounding error is introduced at this step.

Why does my WebVTT file need the word WEBVTT on the first line?

Because the WebVTT specification requires that signature as the file header; a file without it is not a WebVTT file and browsers will reject it. The converter writes it for you, so do not delete it when you edit the output, and watch out for editors that insert a byte order mark ahead of it.

Which browsers can play the WebVTT file this produces?

Support is effectively universal on modern browsers — caniuse reports about 96.7% global support, covering Chrome 23+, Edge 12+, Safari 6+ and Firefox 31+, with Opera Mini the notable holdout. The file has to be attached with a <track> element and served as text/vtt.

Can I convert several STL files at once on this page?

Not in one action. The file control is a single-file picker with no drag-and-drop and no multi-select, so files go through one at a time. Because the parse is instant and local, the practical way to do a batch is to convert each file and use *� Copy rather than saving thirteen downloads.

What happens to the | character in my STL cues?

It becomes a real line break. Spruce STL uses | as its in-cue row separator, so First row|Second row arrives in the WebVTT payload as two physical lines inside one cue. If you need a literal pipe character in the visible text, it will be turned into a break instead — there is no escape for it.