Turn plain TXT subtitle text into a TTML subtitle file in seconds—right in your browser.
<p> element inside a valid <tt> XML document with xmlns="http://www.w3.org/ns/ttml" and an xml:lang attribute so the file passes W3C TTML1 schema checks.<p> with begin/end attributes — you can then re-time inside your subtitling editor. If your TXT already has SRT-style timing blocks, those timecodes carry through verbatim..ttml file. No sign-up, no watermark, no email gate. The XML opens directly in Subtitle Edit, EZTitles, Final Cut Pro X, Adobe Premiere, or any IMSC-aware player.TXT is a universal container — anything from a typed transcript to an exported caption file can land in .txt form — but it carries no styling, no XML schema, and no guaranteed timing. TTML (Timed Text Markup Language) is the W3C-standardized XML format that broadcasters, OTT platforms, and accessibility regulators expect for captions and subtitles. Converting TXT to TTML turns a free-form transcript into a structured, validatable, distribution-ready caption file.
xml:lang on the root <tt> element and percentage-based positioning. A TXT transcript from a transcription vendor becomes ingestable only after TTML wrapping.| Property | TXT | TTML |
|---|---|---|
| File type | Plain UTF-8 / ASCII / UTF-16 text | XML document (.ttml or .xml) |
| Structure | Free-form lines, optional blank-line separators | <tt> root → <head> (styling, layout) + <body> → <div> → <p> cues |
| Timing | None, or ad-hoc inline timestamps | Required begin / end (or dur) attributes on every <p> cue, in clock-time or SMPTE timecode |
| Styling | None | CSS-like properties via tts: namespace — fontSize, color, backgroundColor, textAlign, displayAlign |
| Positioning | None | tts:origin / tts:extent regions defined in <layout>, applied per-cue or per-region |
| Language tag | None | xml:lang required on root <tt> element |
| Validation | No schema | Validates against W3C TTML1 / TTML2 / IMSC schemas |
| Where it's used | Source transcripts, untyped exports | Netflix, BBC iPlayer, Disney+, Prime Video, DVB broadcast, HbbTV, IMF masters |
| Bytes per cue | ~30–60 (text only) | ~100–200 (text + XML tags + timing attributes) |
| Standards body | None | W3C Timed Text Working Group |
| Profile | Defined by | Used by | Key constraints vs base TTML |
|---|---|---|---|
| TTML1 (base) | W3C TTML1 Recommendation | Generic interchange, archival | Full feature set; permissive |
| TTML2 | W3C TTML2 Recommendation (2018) | Newer authoring tools, ruby text, vertical text | Adds ruby, IPA, audio, animation |
| IMSC 1.1 Text Profile | W3C IMSC 1.1 (2018) | Netflix, OTT delivery, IMF | Media-time only (no SMPTE); restricted styling subset |
| IMSC 1.1 Image Profile | W3C IMSC 1.1 | OTT with bitmap captions | Uses PNG image cues instead of text |
| EBU-TT-D | EBU Tech 3380 | BBC, DVB, HbbTV, Freeview Play | Profile of TTML1; strict region/styling subset for distribution |
| SMPTE-TT | SMPTE ST 2052-1 | FCC safe-harbor interchange (US) | TTML1 superset; allows SMPTE timecode and image captions |
| DFXP | Earlier W3C draft (deprecated name for TTML1) | Legacy Flash, older captioning tools | Functionally TTML1; just an older filename convention |
The base XML structure is the same across all profiles, so a TTML output from this converter is a valid starting point. Profile-specific tightening (removing pixel values for Netflix, switching to media-time for IMSC, applying EBU-TT-D regions) is a downstream edit in a subtitle editor.
Not automatically. Netflix's TTML delivery spec demands percentage-only positioning, no pixel values, xml:lang on the root <tt> element, and either SMPTE timecode with ttp:timeBase="smpte" and a frame-rate declaration, or media-time. This converter produces a schema-valid TTML1 document that opens in Netflix-compatible tools (EZTitles, Subtitle Edit, MacCaption), but you'll still need to adjust styling, regions, and time base inside one of those tools before submitting for QC. Treat the output as a clean foundation, not a finished deliverable.
If the converter detects no timing patterns (no HH:MM:SS,mmm, HH:MM:SS.mmm, or SMPTE HH:MM:SS:FF markers), each non-empty line becomes one <p> cue with a default sequential duration (commonly 2–3 seconds per cue). The cues are valid XML and visible in any TTML player, but the timing is placeholder — you must re-time inside a subtitling editor (Subtitle Edit, Aegisub, EZTitles) against the actual audio.
XML overhead. Every cue is wrapped in <p begin="..." end="...">...</p>, the file carries a <head> with namespace declarations and optional styling, and TTML profiles often include a <layout> block with region definitions. A 5 KB TXT transcript routinely produces a 15–25 KB TTML file, which is normal and expected. The size grows with the number of cues, not the length of any individual cue's text.
Yes — TTML is just XML and opens in any text editor. To italicize a word, wrap it in <span tts:fontStyle="italic">word</span>. To color a speaker's lines, add a <style xml:id="red" tts:color="red"/> to <head> and reference it with style="red" on the <p>. To reposition, define regions in <layout> with tts:origin and tts:extent (percentages, not pixels, if you're targeting Netflix). For complex styling, doing it in Subtitle Edit or EZTitles is faster and less error-prone than hand-editing XML.
DFXP (Distribution Format Exchange Profile) was the working name used during the W3C drafting process; once TTML1 became a Recommendation in 2010, DFXP was effectively renamed TTML. Files with a .dfxp extension and files with a .ttml extension are the same XML format — both validate against the W3C TTML1 schema. Some legacy Flash-era captioning tools still produce .dfxp filenames; you can rename the extension to .ttml with no other changes.
Yes. If your TXT was exported with SRT-like blocks — a cue number, an HH:MM:SS,mmm --> HH:MM:SS,mmm line, then one or more text lines, separated by a blank line — the converter parses each block as a cue, converts the comma decimal separator to a period (TTML uses HH:MM:SS.mmm), and writes each as a <p begin="..." end="..."> element. Speaker labels like >> NAME: and HTML-style <i> tags carry through to the <p> text content; full italics styling requires a post-conversion edit to wrap them in <span tts:fontStyle="italic">.
The most common causes, in order: missing xml:lang attribute on <tt> (required by IMSC and Netflix); unescaped ampersands or angle brackets inside cue text (use &, <, >); a mismatched or unclosed tag from a hand edit; using pixel values where the profile expects percentages; or declaring ttp:timeBase="smpte" without a corresponding ttp:frameRate. Run the output through a TTML validator (the W3C IMSC validator at sandflow.github.io, or the imscJS library) to see line-numbered errors.
VLC plays TTML sidecar files with most video formats since version 3.0 (released February 2018), and Safari supports TTML in HLS streams. Chrome, Firefox, and Edge do not natively play standalone TTML files in an HTML5 <video> <track> element — those expect WebVTT. For broad in-browser playback, convert the TTML to VTT after authoring. TTML's role is upstream of the player: it's an interchange and distribution format, not a browser-native one.
Yes. The converter reads the TXT as UTF-8, strips a leading UTF-8 BOM (EF BB BF) if present, and writes the output as UTF-8 with an explicit <?xml version="1.0" encoding="UTF-8"?> declaration. If your TXT is in another encoding (Windows-1252, Shift-JIS, UTF-16), open it in a text editor and re-save as UTF-8 before uploading — TTML is XML and must declare its encoding accurately or downstream parsers will reject it.
No. The TXT-to-TTML conversion runs entirely in your browser session — the parser, XML serializer, and download are all client-side JavaScript. The file never reaches a server and there's no account, watermark, or file-count cap.