Convert WebVTT (.vtt) subtitles to DFXP quickly and download the converted subtitle file in seconds.
.vtt file or click "Add Files" to select one from your device. You can also paste the raw WebVTT text directly into the editor — useful when you've copied cues from a YouTube auto-caption download, a browser DevTools network capture, or a streaming-player track. Batch uploads run in a single pass.HH:MM:SS.mmm into TTML's HH:MM:SS.mmm time-expression syntax), and basic line breaks..dfxp file. The conversion runs entirely in your browser — your subtitle file never leaves your device, so confidential pre-release scripts and unannounced episode dialogue stay on your machine.WebVTT is the W3C standard for HTML5 <track> captions and is what every modern browser plays natively, but most professional and broadcast workflows still expect XML-based timed text. DFXP (the original name for what the W3C later finalized as TTML1 in November 2010) is the lingua franca for handing captions between editorial, QC, encoding, and distribution teams — and many ingest systems will simply reject a .vtt. Typical reasons to convert:
.xml or .ttml) for every language except Japanese; the older .dfxp extension is still accepted by many partner pipelines built around it..dfxp (Premiere also supports .ttml/.xml) for closed-caption tracks, while several older Avid workflows still expect the .dfxp extension specifically.tts:fontSize, tts:color, tts:backgroundColor, tts:textAlign, region positioning, and italic/bold tagging that survives round-trips between captioning tools. WebVTT styling via ::cue is CSS-only and is stripped by most players that re-encode for HLS or DASH..vtt would silently pass.Need the reverse, or a different output format? Use DFXP to VTT to web-encode for HTML5 players, VTT to TTML for the modern .ttml/.xml extension Netflix prefers, or VTT to SRT for editors that only accept SubRip.
| Property | WebVTT (.vtt) | DFXP (.dfxp) |
|---|---|---|
| Standards body | W3C (Candidate Recommendation Draft, WHATWG draft 2010) | W3C TTML1 — DFXP draft 2004; TTML1 Recommendation November 2010 |
| Syntax | Plain text, line-based cues with --> separator |
XML with <tt> root, <body>/<div>/<p> cue tree |
| MIME type | text/vtt |
application/ttml+xml |
| File extensions | .vtt |
.dfxp, .ttml, .xml |
| Timecode format | HH:MM:SS.mmm (millisecond precision) |
HH:MM:SS.mmm or HH:MM:SS:FF (frame-accurate, with ttp:frameRate) |
| Styling | CSS via ::cue pseudo-element (stripped by many players) |
Inline tts: attributes (fontSize, color, textAlign, displayAlign) carried through |
| Positioning | position, line, align cue settings |
<region> elements with tts:origin and tts:extent |
| Native browser playback | Yes — <track kind="subtitles" src="...vtt"> |
No — must be converted or rendered by a JS player |
| Primary use case | Web video, HTML5 <video>, HLS sidecar |
Broadcast, OTT delivery, editorial round-trips |
| Profile | What it is | When to use |
|---|---|---|
| DFXP (.dfxp) | The original W3C Distribution Format Exchange Profile; functionally a subset of TTML1 | Player and platform pipelines that specifically ask for .dfxp; legacy Brightcove, Ooyala-derived, and Premiere closed-caption workflows |
| TTML1 (.ttml / .xml) | W3C Recommendation finalized November 2010; the formally named successor to DFXP | Netflix non-Japanese deliveries, MPEG-DASH/HLS sidecars, modern editorial round-trips |
| TTML2 (.ttml) | Finalized November 2018; adds ruby, multi-region, more layout/styling features | Rare in delivery; mostly used by authoring tools that need richer styling |
| IMSC 1.1 (.xml) | SMPTE/W3C profile of TTML for media subtitles; required by Netflix for Japanese | Japanese subs to Netflix, broadcast-grade IMSC pipelines |
| EBU-TT / EBU-TT-D (.xml) | European Broadcasting Union profile of TTML | EBU member broadcasters, DVB subtitle delivery in Europe |
All five share the same xmlns="http://www.w3.org/ns/ttml" root namespace, so a DFXP file produced here is structurally a valid TTML1 document — many tools will accept it if you rename the extension to .ttml or .xml.
Practically, yes — DFXP was the original 2004 working-draft name ("Distribution Format Exchange Profile"), and the W3C rebranded it as Timed Text Markup Language when TTML1 reached Recommendation status in November 2010. The two share the http://www.w3.org/ns/ttml namespace and a .dfxp file will validate as TTML1. The difference today is the file extension and the audience: pipelines built around the older spec expect .dfxp, while Netflix and modern delivery specs ask for .ttml or .xml.
VTT uses millisecond precision (HH:MM:SS.mmm). DFXP supports the same millisecond form and an optional frame-based form (HH:MM:SS:FF) when ttp:frameRate is declared. This converter outputs millisecond timecodes, which round-trip losslessly back to VTT, SRT, and most NLEs. If your broadcast spec demands HH:MM:SS:FF at a specific frame rate, use a captioning tool (EZTitles, Subtitle Edit, MacCaption) to re-stamp the file after conversion — frame conversion needs the source video's exact frame rate, which a text-only converter can't infer.
::cue CSS carry over?WebVTT styling lives in a CSS-like block (STYLE or external ::cue rules) and most player pipelines strip it before delivery. This converter preserves cue text, line breaks, and timing; it does not attempt to translate CSS into tts: attributes (the mapping is lossy and player-dependent). If your source has critical styling, author it in DFXP/TTML directly or use a tool like Subtitle Edit that exposes tts:color, tts:backgroundColor, and region positioning.
.ttml or .xml instead of .dfxp now?Netflix's Timed Text Style Guide consolidated on TTML1 (and IMSC 1.1 for Japanese) so all submissions go through one schema validator. The .dfxp extension still represents valid TTML1 internally — partners with older DFXP authoring tooling can usually rename to .ttml without re-exporting, but check with your delivery contact. For non-Netflix OTT (Amazon Prime Video, Disney+, Apple TV+), the requested extension varies by partner.
NOTE blocks and chapter cues — what happens to them?WebVTT NOTE comments are stripped (DFXP has no equivalent comment form inside the cue body, only XML comments outside the timed text). Chapter cues (kind=chapters) are not part of the subtitle text stream; if your file contains them, separate them from the caption cues before converting — DFXP is strictly for timed text presentation, not navigation chapters.
Yes — the emitted XML uses the W3C TTML namespace declaration (xmlns="http://www.w3.org/ns/ttml"), declares xmlns:tts for styling and xmlns:ttp for parameters where needed, and structures cues under <tt><body><div><p> per the spec. You can validate the output with the W3C TTML2 validator or any XML schema-aware editor. If a downstream tool rejects it, the most common cause is a missing xml:lang attribute on <tt> — add xml:lang="en" (or the appropriate BCP-47 tag) at the root.
Yes — drop every .vtt into the uploader and each one converts to its matching .dfxp in the same browser session. There's no file-count cap or watermark, and because conversion runs locally, batch performance scales with your CPU rather than a server queue.
No. The converter parses VTT, builds the DFXP XML, and writes the output file entirely in JavaScript in your browser tab. The file never traverses the network, which matters for pre-release episode scripts, NDA-covered dialogue, and any subtitle data you'd otherwise hesitate to paste into a public converter.
DFXP is XML, so opening it in a basic editor that doesn't pretty-print may show one long line. Open it in a code editor with XML formatting (VS Code, Sublime, Notepad++), or rename the extension to .xml and open in a browser to see the cue tree. If the cue count in the converter's preview matched your VTT, the file contains the data.