Caption Format Reference
DFXP File Format (.dfxp)
DFXP is TTML wearing a different extension. It was the original distribution profile of TTML 1.0, it became the name everyone used during the Flash era, and it survives today mostly because platform specifications written a decade ago still ask for it.
Is a DFXP file the same as a TTML file?
Effectively yes. DFXP is the distribution profile of TTML 1.0, so a .dfxp file contains TTML XML. The extension signals which profile a platform expects rather than a different format, which is why renaming works sometimes and fails validation other times.
DFXP at a glance
Because DFXP is a profile rather than a separate format, almost everything in the TTML reference applies here. What differs is which attributes a receiving platform insists on.
| Property | Value |
|---|---|
| Full name | Distribution Format Exchange Profile |
| Extension | .dfxp |
| Underlying format | TTML 1.0 XML |
| Specification | W3C, as a profile of TTML |
| File encoding | XML, normally UTF-8 |
| Timing model | Explicit begin and end, or begin and duration |
| Positioning | Named regions expressed as percentages of the frame |
| Styling | TTML styling: colour, background, font, alignment |
| Common variants | Platform-specific flavours with their own required attributes |
| Current status | Largely superseded by IMSC for new deliveries |
| Closed Caption Creator | Read and write, including platform variants |
For how DFXP sits alongside TTML, SMPTE-TT and IMSC, see TTML, DFXP and IMSC explained.
What DFXP can and cannot carry
DFXP carries what TTML 1.0 carries. The features added by TTML2 and IMSC 1.1 — ruby, text combination, HDR signalling — are not available.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | Unicode XML content |
| Explicit begin and end times | Yes | Or a begin plus a duration |
| Positioning | Yes | Named regions as percentages of the frame |
| Multiple regions on screen | Yes | Independently positioned |
| Text colour and background | Yes | Arbitrary colours with opacity |
| Font family and size | Yes | Requested by the file, honoured at the player's discretion |
| Italics, bold, underline | Yes | As style attributes |
| Forced-display signalling | No | An IMSC addition, not available in DFXP |
| Ruby and CJK text combination | No | Requires IMSC 1.1 or TTML2 |
| Bitmap subtitles | No | Requires the IMSC image profile |
| Multiple languages in one file | Yes | Through xml:lang on separate divisions |
Who still asks for DFXP files?
New specifications rarely name DFXP. It persists in workflows and platform requirements written before IMSC became the standard answer.
- Platforms with long-standing delivery specifications that were never rewritten.
- Legacy media asset management systems configured to expect the extension.
- Archive subtitle assets produced during the Flash and early OTT era.
- Vendors whose downstream tooling matches on file extension rather than on content.
For anything new, IMSC is the better target. It is a more tightly specified profile of the same underlying TTML, and it is what current platform specifications name.
How do I open a DFXP file?
A DFXP file is XML and opens in any text editor. It will look exactly like a TTML document, because it is one — a tt root element, a head with styling and layout, and a body containing timed paragraphs.
The root element usually carries a profile declaration. That declaration, rather than the extension, is what a strict validator reads to decide whether the file conforms.
As with TTML, the subtitle elements reference regions and styles defined in the head, so reading the body alone will not tell you where anything appears on screen.
Converting DFXP to another format
Converting out of DFXP is the TTML conversion in every respect. The table below is included for completeness; the TTML reference covers the same ground in more depth.
| Convert DFXP to | What survives | What to watch for |
|---|---|---|
| IMSC | Everything, usually | The recommended migration. Declare the target IMSC version and validate against it. |
| TTML | Everything | Effectively a relabel, subject to the receiving validator's profile expectations. |
| WebVTT | Text, approximate positioning | Regions flatten into cue settings. Font and size requests are dropped. |
| SRT | Text and line breaks | All styling and positioning discarded. |
| SCC | Text, italics, approximate placement | Colours reduce to seven, regions snap to a character grid, output must be 29.97 fps. |
| MCC | Text, styling, placement | More styling survives, and the frame rate is a choice rather than a constraint. |
| EBU-STL | Text, colour, placement | Regions become teletext rows, and a 25 fps timing base is required. |
Converting another format to DFXP
Converting into DFXP is worth questioning before you do it. Unless a specification explicitly names DFXP, IMSC is the better destination for the same content.
| Convert to DFXP from | What carries over | What the conversion has to decide |
|---|---|---|
| TTML / IMSC | Everything | Which profile to declare, and removing features TTML 1.0 does not support. |
| WebVTT | Text, positioning, basic styling | How cue settings become named regions, and what default styling to author. |
| SRT | Text and line breaks | A complete region and style model from nothing. |
| SCC | Text, italics, placement | Whether to preserve the character grid as regions or normalise placement. |
| EBU-STL | Text, colour, placement | Teletext rows become percentage regions and the palette becomes explicit colours. |
Closed Caption Creator reads and writes every format in both tables, including platform-specific DFXP variants. See the full file format support list.
Where DFXP deliveries go wrong
DFXP problems are nearly always about conformance to a particular flavour rather than about the subtitles themselves.
- Renaming instead of converting. Changing
.ttmlto.dfxpsatisfies a filename check and nothing else. A strict validator reads the profile declaration inside the document. - Ignoring a platform variant's requirements. Some platforms define their own constrained DFXP with required attributes. A generic DFXP export will pass general validation and fail theirs.
- Assuming IMSC features are available. Forced-display signalling, ruby and text combination are not part of DFXP. Content relying on them loses those features on the way in.
- Delivering DFXP where IMSC was expected. The two are close enough to look interchangeable and different enough to be rejected. Read the spec rather than the extension.
For the wider timed text family and how to choose between profiles, see TTML, DFXP and IMSC explained.
DFXP conversion questions
Common questions about moving subtitles into and out of the DFXP format.
Often it works, and sometimes it fails for a reason that has nothing to do with the rename. Both files contain TTML XML, so any tool reading the content will be satisfied. A strict validator reads the profile declaration in the root element instead, and a platform expecting a specific profile will reject a file that declares a different one however it is named.
Mostly ones whose delivery specifications predate IMSC and were never updated, along with legacy asset management systems that match on the extension. New specifications name IMSC. If you are choosing rather than following a spec, choose IMSC — it is the same underlying format, more tightly defined.
Yes, with the same reductions as any TTML conversion. Arbitrary colours become the seven CEA-608 colours, percentage regions snap onto a 32 by 15 character grid, and the output must be 29.97 fps. If the DFXP was authored against a 25 or 23.976 fps master, conform it before exporting rather than after.
Not necessarily. Several platforms define their own constrained flavour, with required attributes, a fixed set of permitted styling, and their own validator. A generic DFXP export is valid DFXP and can still be rejected. Export using a profile built for that platform when one is available.
The usual causes are a profile declaration that does not match what the platform expects, a required attribute the exporter did not write, or a styling feature outside the permitted set. Validate against the platform's published requirements rather than against TTML generally, because a technically valid document can still be non-conformant.
If the files are still being delivered anywhere, yes. IMSC is the current profile, is what new specifications name, and adds forced-display signalling that DFXP cannot express. The conversion is light because the underlying XML is the same. If the archive is purely for preservation, there is no urgency — DFXP is readable and well documented.
Read legacy DFXP, deliver current formats
Closed Caption Creator reads DFXP including platform-specific variants, and exports to IMSC, TTML, WebVTT, SCC and MCC from the same project.
Migrate a legacy subtitle archive to a current profile without re-timing anything.