Turn a TXT subtitle file into a DFXP subtitle file in just a few clicks—fast, simple, and works right in your browser.
.txt transcripts from your device, or paste plain text directly. Batch upload is supported — convert a season of dialogue scripts in a single pass. Files stay in your browser session; nothing is uploaded..dfxp) — an XML profile of W3C TTML1 used by Netflix, Amazon Prime Video, and most professional captioning workflows. UTF-8 encoding is applied automatically so non-ASCII characters (accents, smart quotes, CJK) survive intact..txt files carry no timecodes, so the converter assigns sequential cues — one subtitle per non-empty line. Edit the resulting DFXP in a captioning editor (Subtitle Edit, Aegisub, EZTitles) to line up begin/end attributes with your video before delivery..dfxp file. No sign-up, no watermark, no 5-file daily cap.DFXP (Distribution Format Exchange Profile) is the original name for a TTML1 profile that the W3C finalized as a Recommendation in November 2010; the term persists because broadcasters, streaming platforms, and professional caption tools still ship .dfxp as a standard delivery extension. Plain .txt is the lowest-effort starting point for a script — but it has no timing, no styling, and no structure a video player can use. Converting bridges that gap. Typical scenarios:
.dfxp or .xml extension; Amazon Prime Video accepts DFXP Full / TTML (.dfxp), iTT, and SRT for subtitle deliveries. Both platforms mandate UTF-8 encoding and reject Windows-1252 or UTF-16 files outright..txt script with one line per cue. Converting to DFXP gets you a structurally valid XML skeleton with cue IDs, <p> elements, and placeholder begin/end attributes you then time against the video..dfxp/.xml TTML as captions on a dedicated track, where Premiere's older .srt workflow flattens styling. DFXP preserves italic and language metadata across round-trips..txt requires manual cue boundary detection. One DFXP file becomes the source for every target language with timing reused..dfxp works across your CMS, LMS, and OTT app without re-export.A converter to .txt (no timing) is the right tool when you want to start from a script; for line-by-line transcripts that already have timecodes, an SRT-to-DFXP step preserves the timing instead of discarding it.
| Property | TXT (plain text) | DFXP (TTML1 profile) |
|---|---|---|
| Structure | Free-form lines of text | XML with <tt><head><body><div><p> hierarchy |
| Timing | None — implied by line order | Explicit begin/end attributes per <p> cue |
| Styling | None | Font, color, italic, bold, position, language tags |
| Encoding | ANSI, UTF-8, UTF-16, etc. (no standard) | UTF-8 is the de facto requirement for delivery |
| File extension | .txt |
.dfxp (also .xml for Netflix) |
| Standard body | None | W3C TTML1, Recommendation Nov 2010 |
| Used by | Authors, transcribers, internal review | Netflix, Amazon Prime, Vimeo, broadcasters, OTT |
| Round-trip safe? | Yes — but you lose timing on export | Yes — preserves cue IDs, styles, regions |
| Best paired with | Internal scripts, voice-over prep | Final delivery, professional captioning workflows |
The naming is genuinely confusing because the W3C renamed the spec mid-stream. Quick reference:
| Name | What it is | When to pick it |
|---|---|---|
| DFXP | The original 2005 working-draft name; today, a TTML1 profile (Full / Presentation / Transformation) | Netflix .dfxp deliveries, legacy broadcast workflows |
| TTML1 | The 2010 W3C Recommendation — same wire format as DFXP Full, different filename | Generic interchange, when a partner asks for "TTML" |
| TTML2 | Updated 2018 W3C Recommendation with richer styling, animation, ruby text | Modern web players, IMSC-based deliveries |
| IMSC 1.x | A constrained TTML profile (IMSC 1.0.1 Text and Image profiles) widely used in HLS | Apple HLS captions, ATSC 3.0 broadcast |
| SMPTE-TT | A SMPTE-standardized extension of DFXP adding bitmap and binary support | U.S. broadcast — FCC safe-harbor format since Feb 2012 |
In practice, .dfxp files produced by xconvert are TTML1-compliant XML — most players accept them under either name.
Plain .txt has no timing information, so the converter assigns sequential placeholder cues — one cue per non-empty line, with begin and end attributes spaced evenly. To match your audio, open the .dfxp in a captioning editor (free options: Subtitle Edit on Windows/Linux/macOS via Mono, Aegisub, or Jubler) and shift each cue's timing against the waveform. If you already have a timed source like SRT, SBV, or VTT, converting from that format instead preserves the existing timecodes.
Structurally yes — it's valid TTML1 XML — but Netflix's Timed Text Style Guide also requires specific positioning (percentage-based tts:origin and tts:extent, never pixel values), a frame-rate declaration in the <tt> root attributes (ttp:frameRate), white text only for general SDH, and a strict reading-speed cap. A bare conversion from .txt won't include any of that. Treat the output as a starting XML skeleton — then add Netflix-required metadata in your captioning editor before delivery.
For most practical purposes, yes. DFXP was the W3C's 2005 working-draft name; when the spec was finalized in November 2010 it was renamed TTML1, but the file format itself didn't change. DFXP today refers to a profile of TTML1 (Full, Presentation, or Transformation). A .dfxp file and a .ttml file with the same content are byte-identical XML — the extension is a delivery convention.
UTF-8 with no BOM. This matches the requirements published by Amazon Prime Video (which rejects anything other than UTF-8) and the de facto delivery standard at Netflix. If your source .txt was saved in Windows-1252 or UTF-16, the converter re-encodes; smart quotes, accented characters, and CJK glyphs survive intact in the resulting DFXP <p> content.
One subtitle cue per line, with a blank line separating cues if you want a paragraph break in the styled output. Avoid timestamps in the body — if your .txt already has lines like 00:00:01,000 --> 00:00:04,000, the converter treats them as content, not timing. For files with embedded timecodes, convert from SRT or SBV instead so the timing is parsed correctly.
Yes — DFXP is plain text XML, so any text editor (VS Code, Sublime, Notepad++) will open it, and any XML linter will validate it. Dedicated captioning editors (Subtitle Edit, Aegisub, EZTitles, MacCaption, CaptionMaker) give you a timeline view and validate against platform-specific rules at the same time. Don't hand-edit cue IDs — most editors regenerate them on save.
The XML skeleton produced from .txt is compatible with SDH workflows, but you'll need to add the non-dialogue content yourself — speaker IDs, sound effects in brackets like [door slams], music notes, and any required xml:lang attributes. Most platforms require SDH to mark every audible non-dialogue event; a transcript-only .txt won't include those cues.
DFXP Full supports the entire TTML1 feature set — every styling, layout, and timing capability. DFXP Presentation is the minimum profile a player must support for playback. DFXP Transformation is the minimum profile a conversion tool must support to round-trip into and out of TTML. Files xconvert produces target DFXP Full / TTML1 so they work with both player and authoring pipelines.
Vimeo, JW Player, Kaltura, and Panopto all accept DFXP/TTML as a captions sidecar. YouTube accepts TTML uploads through the Studio captions editor but internally converts everything to its own format. Most learning-management systems (Canvas, Moodle, Blackboard) accept DFXP for HTML5 video players via the standard <track> element. If a target only accepts SRT or VTT, convert again from the timed DFXP rather than re-doing the work from .txt.