Convert a SUB subtitle file to DFXP in seconds—right in your browser for quick playback and editing workflows.
MicroDVD .sub is a text subtitle format from the dial-up era: one line per cue, timings expressed as frame numbers, no header, no schema. DFXP is the opposite — an XML document built on the W3C's Timed Text Markup Language, the format broadcast and OTT pipelines exchange captions in. Converting between them means turning frame counts into real timestamps and wrapping plain lines in an XML tree, which this page does entirely inside your browser. Two things need your attention on the way through, and both are covered below: the frame rate, and the fact that the emitter does not escape XML special characters for you.
| Property | Value |
|---|---|
| Origin | Tiamat Software's MicroDVD Player, first released March 2000; development ended 2001 |
| Standard | None — a de facto convention, never standardised |
| Cue syntax | {start_frame}{end_frame}text, one cue per line |
| Timing model | Frame numbers, relative to a video's frame rate |
| Frame rate | Not part of the syntax; by convention declared as a first cue, {1}{1}23.976 |
| Line breaks | The pipe character ` |
| Styling | Inline codes: {y:i} italic, {y:b} bold, {y:u} underline, {c:$BBGGRR} colour in reversed byte order, {f:name} font, {s:n} size |
| Positioning | None |
| Encoding | Unspecified — legacy files are frequently Windows-125x or Big5 |
| Property | Value |
|---|---|
| Standard | Timed Text Markup Language 1 (TTML1), a W3C Recommendation — Third Edition, 8 November 2018 |
| What DFXP stands for | Distribution Format Exchange Profile, TTML's original name, retained in profile names and legacy URLs |
| Root element | tt |
| Namespace | http://www.w3.org/ns/ttml, with styling in http://www.w3.org/ns/ttml#styling |
| Media type | application/ttml+xml |
| File extension | Not defined by the spec — .dfxp and .ttml are both conventions |
| Timing model | Clock time, offset time or SMPTE frames; this converter writes clock time |
| Styling | A full CSS-derived styling and layout model, including regions |
| Platform support | YouTube accepts TTML with styling and positioning, and supports SMPTE-TT extensions for CEA-608 features |
{start}{end}text lines into the Input (SUB) box; the character counter beside the label confirms it read.& with & in the input first; otherwise the resulting document will not parse..sub reads {1}{1}23.976. This parser reads every MicroDVD file at 25 fps and offers no frame-rate field, so anything else means the begin and end values need verifying — delete that line before converting either way.subtitles.dfxp — or "📋 Copy". Run the result through an XML validator and check the timings against the video before handing it to a delivery pipeline.The output follows the shape of a minimal TTML1 document. It declares the tt and tts namespaces, opens a single body → div, and writes one p per cue with begin and end in hh:mm:ss.mmm clock time:
| Element | What is emitted |
|---|---|
| XML declaration | <?xml version="1.0" encoding="UTF-8"?> |
| Root | <tt xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling"> |
| Structure | One body, one div, one p per cue — no head, no styling, no layout, no region |
| Timing | begin="00:00:01.000" end="00:00:04.000" — clock time, millisecond precision |
| Line breaks | MicroDVD's ` |
| Language | No xml:lang attribute is written |
One important caveat comes with that structure: cue text is written into the p element without XML escaping. A caption containing & or < — "R&B", "AT&T", "Fish & chips", or any leftover <i> markup — produces a document that is not well-formed, and parsers reject it outright rather than degrade gracefully. Escape those characters in the .sub before converting (& passes through cleanly and validates), and run the finished file through an XML validator.
Beyond that, the document is deliberately spare, and well short of what a broadcast delivery spec will ask for. Netflix-style or EBU-TT-D deliveries expect a populated head with styling and layout, an explicit xml:lang, and often a ttp:frameRate — all of which you add downstream. Treat this output as a timing-and-text skeleton to build on, not a delivery master.
{25}{100}Hello means "frames 25 through 100". Converting that into begin="00:00:01.000" requires the frame rate of the video it was cut against, and MicroDVD has nowhere in its syntax to put one. The convention is to write it as a first cue, {1}{1}23.976: FFmpeg's MicroDVD demuxer scans the opening lines for that shape, and the reference Python implementation pysubs2 refuses a MicroDVD file outright — UnknownFPSError — when neither an explicit rate nor that hint is available. That is a fair measure of how underdetermined the format is on its own.
This converter does not read the hint line and renders no frame-rate control, so every MicroDVD file is parsed at 25 fps. Delete the hint line before converting, since it will otherwise become a <p> element whose text is the number. And treat the begin and end attributes as provisional: check them against the video before the document goes anywhere near a delivery pipeline, where a timing error is expensive to discover late.
The arithmetic is easy to verify by hand — frame number divided by frame rate gives the time in seconds:
| Frame number | at 23.976 fps | at 24 fps | at 25 fps | at 29.97 fps | at 30 fps |
|---|---|---|---|---|---|
| 24 | 0:00:01.001 | 0:00:01.000 | 0:00:00.960 | 0:00:00.801 | 0:00:00.800 |
| 1,500 | 0:01:02.563 | 0:01:02.500 | 0:01:00.000 | 0:00:50.050 | 0:00:50.000 |
| 90,000 | 1:02:33.754 | 1:02:30.000 | 1:00:00.000 | 0:50:03.003 | 0:50:00.000 |
A frame-rate mismatch is not a constant offset. It accumulates over the runtime, which is why it survives a spot check on the first minute:
| Source authored at | Read at 25 fps, cues land | After 1 minute | After 10 minutes | After 1 hour |
|---|---|---|---|---|
| 23.976 fps | early | 2.5 s early | 24.6 s early | 2 min 28 s early |
| 24 fps | early | 2.4 s early | 24.0 s early | 2 min 24 s early |
| 29.97 fps | late | 11.9 s late | 1 min 59 s late | 11 min 56 s late |
| 30 fps | late | 12.0 s late | 2 min 0 s late | 12 min 0 s late |
Two further input quirks affect what reaches the document. A UTF-8 byte-order mark at the head of the .sub makes the first line unmatchable — the cue pattern is anchored to an opening { — so the first caption disappears without a warning, and Windows-authored files frequently carry a BOM. And a cue with an empty end frame, {1234}{}, is skipped, because this parser requires digits in both braces.
Effectively, yes. DFXP — Distribution Format Exchange Profile — was the working name for what the W3C published as Timed Text Markup Language, and the abbreviation survives in profile identifiers and file extensions long after the specification was renamed. A .dfxp and a .ttml file with the same content are the same document; the extension is a convention the spec itself does not define. This page writes the TTML1 namespace either way.
Almost certainly an ampersand or an angle bracket in the dialogue. The emitter inserts cue text into the p element without escaping it, so a line reading Tom & Jerry produces <p ...>Tom & Jerry</p>, which any XML parser rejects with an error about an unexpected &. The fix is to escape in the source: write Tom & Jerry in the .sub before converting, and the entity passes through to a document that validates. Angle brackets are worse — a < and a > on the same line get treated as a tag and the text between them is removed.
No. The tts styling namespace is declared on the root element but no head, styling, layout or region is written, and no style attributes appear on the p elements. Every cue therefore renders with the player's default caption presentation. This is deliberate for a MicroDVD source, since the incoming styling is line-level inline codes with no positioning model to map onto TTML regions.
They do not. {y:i}, {y:b}, {c:$0000ff}, {f:Arial} and {s:12} are stripped during parsing, so the p elements contain plain text. If styling matters more than portability, SUB to ASS at least gives you a real style table to edit, though the inline codes are dropped on that route too.
YouTube lists TTML among the caption formats it accepts and describes its support as partial, with styling and positioning supported and SMPTE-TT extensions handled for CEA-608 features. In practice a much simpler format is a better bet for a plain dialogue track: SUB to SBV targets YouTube's own SubViewer flavour, and SRT is accepted almost everywhere. Reach for DFXP when a delivery spec asks for it.
Clock time, written as hh:mm:ss.mmm. TTML1 also permits offset times such as 4.5s and SMPTE frame-based timing with a ttp:frameRate parameter, and a MicroDVD source might look like a natural fit for the SMPTE model. This converter does not use it: frames are resolved to milliseconds during parsing and the original frame numbers are not preserved anywhere in the output.
Nothing is lost. The parser matches exactly one pattern — {digits}{digits} followed by text — and ignores every line that does not fit. If no line fits, the page shows "No cues parsed from input. Check the format." and produces no output. That is the usual outcome when the .sub is actually VobSub, the binary bitmap format that ships alongside an .idx file, or a SubViewer .sub with hh:mm:ss timestamps.
In the browser tab. The file is read locally with the FileReader API, parsed and re-emitted by JavaScript that arrived with the page, and returned to you as a Blob download — no request carries your subtitle text off the machine, and there is no server-side copy to expire. If you would rather work from the other direction or target a different format, the SUB converter hub lists the alternatives.