SRT to DFXP Converter

The SRT to DFXP Converter turns the SubRip file you paste into the SRT Content box into a DFXP document - the Distribution Format Exchange Profile of TTML. The output is well-formed, namespaced XML with a head and body, in which every caption is a timed <p> element carrying begin and end attributes, and it downloads with the .dfxp extension.

DFXP shows up wherever captions have to be machine-readable rather than merely playable. Legacy Flash-based players were the original consumers, but the same profile is still requested by online video platforms, media asset management systems, broadcast archives and several enterprise e-learning suites, and TTML is the ancestor of the IMSC profiles used for professional delivery. Distributors, accessibility officers and post-production coordinators regularly receive an SRT from the subtitler and a spec sheet demanding XML, which is exactly the gap this srt to dfxp converter closes.

Under the hood the SubRip parser reads each numbered block, converts the comma-separated timing line into milliseconds, and hands the cue list to the DFXP writer. Timestamps are re-emitted in clock time with a dot before the milliseconds, HH:MM:SS.mmm, which is what the TTML specification requires and the single most common reason a hand-edited file is rejected. Because the output is XML, characters that would otherwise break the document - ampersands and angle brackets in the caption text - have to be escaped, and multi-line captions are represented with a break element rather than a raw newline so the line layout survives the round trip.

The conversion is pure client-side JavaScript: your captions are never uploaded, and large episodic files convert in a fraction of a second.

• Namespaced TTML output: the document is emitted with the proper TTML namespace declarations and a head and body structure, so validators and XML parsers accept it instead of choking on a bare fragment.
• Dot-separated timestamps: SubRip's 00:00:04,500 is rewritten as 00:00:04.500, the clock-time form DFXP requires, which removes the most common cause of a rejected caption sidecar.
• Explicit begin and end: unlike start-anchored formats, each <p> carries both attributes, so cue durations survive exactly as the subtitler set them.
• XML-safe caption text: reserved characters in the SRT Content you paste are escaped during writing, so a line containing an ampersand or a bracket does not produce a malformed file.
• Line breaks preserved: two-line captions stay two lines through a break element rather than collapsing into a single overlong row of text.
• Forgiving input: the parser handles Windows or Unix line endings, missing final blank lines and inconsistent cue numbering without complaint.
• One-click export: the finished XML can be copied or downloaded as a .dfxp file with no account, watermark or file-count limit.

1. Paste the whole SubRip file, cue numbers and timing lines included, into the SRT Content box - this is the tool's only input field.
2. Click Load sample first if you want to see a known-good input and its DFXP result before running your own captions.
3. Press Run to parse the cues and emit the TTML document; the converted XML appears in the output panel straight away.
4. Check the opening element and namespace at the top of the result, then confirm the first <p> shows the begin and end values you expect for cue 1.
5. Verify that the timestamps use a dot before the milliseconds, since that is what your player or platform validator will be testing.
6. Use Copy to paste the XML into a delivery package, or Download to save it as a .dfxp file.
7. Test the saved file in your target player or upload it to the platform that requested DFXP, keeping the original SRT as your editable master.

Example 1 - a single caption becomes a timed paragraph. The SubRip block on the left is emitted as one TTML element.

Input (SRT):
1
00:00:01,000 --> 00:00:04,000
Welcome to the harbour tour.

Output (DFXP):
<p begin="00:00:01.000" end="00:00:04.000">Welcome to the harbour tour.</p>

The comma in the SRT timestamp has become a dot, and the implicit cue duration is now stated explicitly by the pair of attributes.

Example 2 - a two-line caption. A cue whose text reads Mind the gap on one line and between train and platform. on the next is written as a single <p> containing a break element between the two phrases, so the player renders two lines rather than one long line that wraps unpredictably across different screen widths.

• Meets XML delivery specs: when a platform or archive insists on TTML/DFXP, you can satisfy the requirement from the SRT you already have instead of commissioning a new caption pass.
• Avoids rejected uploads: correct namespaces, escaped text and dot-separated clock times mean the file passes the automated checks that quietly bounce hand-written XML.
• Future-proofs your captions: TTML is the base of the IMSC profiles used for modern broadcast and streaming delivery, so a DFXP master is a better long-term archive object than a bare text file.
• Saves specialist software: no need for a licensed authoring suite just to change container format, which matters for occasional or one-off deliveries.
• Keeps content confidential: conversion happens in the browser, so scripts under embargo are never transmitted anywhere.
• Scales to whole series: episodes convert in seconds each, so a full season can be reformatted in the time it takes to open a ticket about it.