Turn TTML subtitle files into plain TXT text in seconds—upload your .ttml, convert, then download the .txt output.
.ttml (or .xml / .dfxp exported as TTML) into the dropzone, or click "Add Files" to browse. Batch upload is supported, so you can flatten an entire season of captions into transcripts in one pass. Everything runs in your browser session — the file never leaves your machine.<p> cue joined into clean plain text..txt file individually or grab a ZIP of the batch. No sign-up, no email gate, no watermark.TTML (Timed Text Markup Language) is the W3C's XML-based caption format — published as a Recommendation in November 2010, with TTML2 finalized in November 2018. It's the interchange standard the broadcast and streaming industries actually use: SMPTE, EBU, ATSC, DVB, HbbTV, and MPEG CMAF all build on it, and the IMSC 1.1 profile is what Netflix mandates for Japanese subtitle delivery. The trade-off is that TTML files are dense XML — useless if you just want the words. Converting to TXT throws away the markup and gives you a readable transcript. Common reasons people do this:
<tt>, <div>, <p begin="...">, and styling attributes.xmlns, tts:, and begin=/end= noise per file.grep -r "trademarked phrase" or load the corpus into BigQuery.Working with a related caption format? See TTML to SRT if you need to keep the timecodes, TTML to VTT for web-video players, or SRT to TXT and VTT to TXT if your source isn't TTML. Going the other direction (a raw transcript back to a caption track), use TXT to TTML.
| Property | TTML | SRT | VTT | TXT (output) |
|---|---|---|---|---|
| Base syntax | XML (W3C) | Numbered cues, plain | WEBVTT header, plain | Plain text only |
| Styling, color, positioning | Yes — rich CSS-like styles, regions, multiple tracks | No (some players accept embedded HTML) | Yes — cue settings, CSS via STYLE blocks | None |
| Timestamp precision | Down to fractional seconds and frames | HH:MM:SS,mmm (comma separator) |
HH:MM:SS.mmm (dot separator) |
None |
| Profiles / variants | TTML1, TTML2, IMSC 1.0/1.1, EBU-TT, SMPTE-TT, DFXP | None — single spec | One spec | n/a |
| Standardized by | W3C (Rec since 2010) | De facto, no formal standard | W3C | n/a |
| Typical industry use | Broadcast TV, OTT (Netflix IMSC), MPEG CMAF | YouTube uploads, social cuts, video editors | HTML5 <track> web video |
Transcripts, AI prompts, archives |
| MIME type | application/ttml+xml |
application/x-subrip (de facto) |
text/vtt |
text/plain |
| Stage | Excerpt |
|---|---|
| Source TTML cue | <p begin="00:00:04.500" end="00:00:07.200" region="bottom" tts:color="white">Welcome to the show.</p> |
| Converted TXT line | Welcome to the show. |
| What gets dropped | begin, end, region, tts:* styling, <div>/<body>/<tt> wrappers, namespaces, metadata |
| What is preserved | Cue text content, paragraph order, line breaks between cues |
| What is optional | Speaker labels (<span tts:fontStyle="italic">Host:</span>) — kept as inline text |
Yes — that's the point of TXT. The output is the spoken text only, with every begin/end attribute, frame reference, and tick-rate stripped out. If you need to preserve timing, convert to TTML to SRT or TTML to VTT instead, both of which keep timestamps in a much simpler form than the source XML.
Yes. IMSC 1.0 and IMSC 1.1 are constrained profiles of TTML, so an .xml or .ttml file authored to IMSC parses with the same XML rules. The converter walks every <p> element regardless of which profile authored it, and styling blocks (<region>, <style>, tts:* attributes) are discarded along with the rest of the markup.
DFXP (Distribution Format Exchange Profile) is an early TTML profile that uses the .dfxp extension but is XML-compatible with TTML1. If your DFXP file parses as XML it will convert here; rename it to .ttml first if the file picker rejects the extension, or use DFXP to TTML to normalize the wrapper before extracting text.
If they're written as text inside a <p> cue (for example [applause], (music swells), or ♪ ♪), they're kept verbatim because the converter doesn't try to distinguish dialogue from non-dialogue. If you want a dialogue-only transcript, you'll need to delete those lines manually in a text editor after conversion — they're easy to spot because they're typically the only lines wrapped in brackets or framed by music-note characters.
Yes. Each <p> cue in the source TTML becomes a separate line (or short paragraph) in the TXT, in the order they appear in the file. This usually matches the visual cadence of the captions. If your source TTML uses one long <p> per scene rather than per line, you'll get fewer, longer TXT lines — that's the source author's choice, not a converter limitation.
Yes — the batch upload supports as many TTML files as your browser can hold in memory. Each input file produces a matching .txt output. You can grab them individually or download a single ZIP after the batch finishes. Everything happens client-side, so there's no per-file API charge or upload bandwidth eaten.
.ttml?The converter expects well-formed XML. A .ttml file produced by a buggy authoring tool may contain unescaped &, mismatched tags, or a missing XML declaration — those all fail the parser. Open the file in any text editor and confirm it starts with <?xml version="1.0"...?> and <tt xmlns="http://www.w3.org/ns/ttml"...>. If the source was renamed from .xml or .dfxp and isn't actually TTML, the namespace will be different and you'll need the matching converter for the real format.
No. This converter runs entirely client-side in your browser using JavaScript — nothing about your TTML, your transcript, your filenames, or your metadata leaves your machine. That's especially relevant for unaired broadcast captions, embargoed press conferences, or anything else where the script is sensitive before publication.