Turn your .sub subtitle file into a .vtt WebVTT subtitle in a few clicks—upload, convert, and download your VTT file.
WebVTT is the only subtitle format a browser will load through <track>, so a .sub file rescued from an old DivX rip has to become .vtt before it can ride along with an HTML5 <video> element. The conversion itself is a re-encoding of frame numbers into clock times — which is why the frame rate, not the syntax, is the part that decides whether the result is usable.
MicroDVD stores {startFrame}{endFrame}text, so frame 1440 is a minute into a 24 fps film but 57.6 seconds into a 25 fps transfer. Nothing inside the numbers tells you which. The format's answer was a convention: put the frame rate on the first line as {1}{1}23.976. FFmpeg's MicroDVD reader looks for exactly that in the first three lines and otherwise falls back to 23.976 fps.
This converter takes a different route, and you should know it before you publish the output:
{1}{1}23.976 header parses as a normal cue and shows up in your VTT as a subtitle reading 23.976. Strip it from the input, or delete the first cue from the output.Play the video with the converted track attached before you ship it. MicroDVD timing scale is an open defect on our side, so the timeline is the thing to verify; the cue text, line breaks and cue order convert reliably.
| Property | MicroDVD (.sub) | WebVTT (.vtt) |
|---|---|---|
| Specification | De facto, from the MicroDVD player era | W3C WebVTT, Candidate Recommendation Draft (May 2026) |
| Timing unit | Frame numbers | Clock time, HH:MM:SS.mmm (hours optional) |
| Decimal separator | Not applicable | Period — unlike SubRip's comma |
| Required first line | None | The literal string WEBVTT |
| Frame rate required to read | Yes | No |
| Line break within a cue | | pipe |
A real newline |
| Styling | {y:i}, {y:b}, {c:$BBGGRR} inline codes |
<i>, <b>, <u>, <c.class> plus CSS via ::cue |
| Positioning | {P:x,y} |
Cue settings: line, position, align, size |
Loads in a browser <track> |
No | Yes — the only format that does |
| Text encoding | Whatever the author used, often a legacy code page | UTF-8, mandatory |
The output this page produces is a minimal, valid WebVTT file: the WEBVTT header, then numbered cue identifiers with --> time ranges. It does not emit cue settings, STYLE blocks or REGION blocks, because a MicroDVD source has no equivalent information to carry into them.
Once you have the file, the markup is a <track> child of your media element. These are the attributes that actually matter:
| Attribute | What it does | Notes |
|---|---|---|
src |
Path to the .vtt |
Must be same-origin as the page, unless the parent <video> carries crossorigin |
kind |
Track role | subtitles is the default; use captions when the track also describes sound |
srclang |
Language of the track | Required whenever kind is subtitles |
label |
Name shown in the player's menu | Free text, e.g. "English" |
default |
Enables this track on load | Only one track per media element may carry it |
Serve the file as text/vtt. A server that hands it back as text/plain or application/octet-stream will often see the track silently fail to display, which looks identical to a broken conversion but is not one.
Because nothing about the contents matches. WebVTT requires the literal word WEBVTT on the first line and clock timestamps such as 00:01:00.000 --> 00:01:04.000. A MicroDVD file starts with {1440}{1560} frame numbers and has no header at all, so a browser reads it, finds no valid signature, and loads an empty track.
25 fps, and it is not adjustable here — there is no frame-rate field in the interface. Worth knowing that this is a genuine fork in the ecosystem rather than a universal default: FFmpeg's MicroDVD demuxer falls back to 23.976 fps for a file that declares nothing, so two respectable tools will give you two different timelines from the same input.
No, and it will cost you a phantom subtitle. We ran a three-cue MicroDVD file with a leading {1}{1}23.976 through the exact parser this page uses and got four cues back — the extra one being a subtitle whose visible text is the string 23.976. Delete that line before converting, or delete the first cue block from the finished VTT.
<i> tags in the VTT?No. MicroDVD's {y:i}, {y:b}, {y:u} and {c:$BBGGRR} codes are stripped together with their braces rather than translated into WebVTT's tag equivalents, so the output is plain unstyled text. If you need emphasis, add the <i> tags to the VTT yourself afterwards — WebVTT supports them natively, and CSS ::cue selectors can style them.
Yes — the format mandates it, and this is the single most common reason a converted track shows question marks or boxes instead of accented characters. Many MicroDVD files from the 2000s are in a legacy code page such as Windows-1250 or Windows-1251. The browser reads your uploaded file as text and cannot infer a legacy encoding, so re-save the .sub as UTF-8 in a text editor before converting.
Work through three causes in order. First, the file may be served with the wrong MIME type — it needs text/vtt. Second, the <track> src has to be same-origin with the page unless the <video> element carries a crossorigin attribute. Third, if kind is subtitles then srclang is required; without it the track can be ignored.
No. This page is client-side: your browser reads the .sub locally, converts it with JavaScript running on the page, and builds the download in memory. The converter's code comes from us; your subtitle file does not go to us.
Not through this conversion. MicroDVD can express placement with {P:x,y}, and WebVTT has a richer system of cue settings — line, position, align and size — but the codes are stripped rather than mapped, so every converted cue lands in the player's default position. Add cue settings by hand if placement matters.
Switch To format to SRT, or start from SUB to SRT. The two formats are close cousins — SubRip uses a comma before the milliseconds and has no WEBVTT header — and if you already have one you can move between them with SRT to VTT.