Turn TTML subtitle files into SRT subtitles in a few clicks—upload your TTML, convert, and download the SRT file.
HH:MM:SS.mmm), offset time (5.2s, 300ms), and tick-based timing, normalizing each to SRT's HH:MM:SS,mmm comma-separated format.<br/> line breaks as SRT line wraps and discards <span> styling that SRT can't represent..srt file. Files process in your browser session — no sign-up, no watermark, no server upload.TTML (Timed Text Markup Language) is a W3C XML standard used by streaming services and broadcasters — Netflix, Disney+, Prime Video, the BBC, and 20th Century Fox all ship captions in TTML profiles like IMSC1.1 or EBU-TT-D. SRT (SubRip) is the lowest-common-denominator subtitle format: numbered cues, plain-text lines, HH:MM:SS,mmm timestamps, nothing else. Converting from TTML to SRT trades professional features (positioning, color, ruby text, multiple regions) for universal playback. Common reasons to do it:
.srt sidecars next to the video file; TTML sidecars require manual embedding or transcoding first.| Property | TTML | SRT |
|---|---|---|
| Extension | .ttml, .dfxp, .xml |
.srt |
| Structure | XML namespaces, regions, styles | Numbered text blocks |
| Timing precision | Tick-based, clock-time, offset-time | Milliseconds (,mmm) |
| Styling | CSS-like (color, font, position, ruby) | None (some players read italic/bold HTML-ish tags) |
| Multiple languages per file | Yes (via xml:lang) |
No — one language per file |
| Positioning | Yes (regions, alignment) | No |
| File size (typical 1h film) | 300-800 KB | 60-120 KB |
| Used by | Netflix, BBC, Disney+, Prime Video | YouTube, VLC, every video editor |
| Standardized by | W3C TTML2 / IMSC1.1 | De facto (SubRip 1.x) |
| Edit with plain text | Painful (verbose XML) | Trivial |
| Element | Behavior on Conversion |
|---|---|
| Dialogue text | Preserved verbatim, including Unicode |
| Cue timing | Preserved — all TTML time formats normalized to SRT milliseconds |
Line breaks (<br/>) |
Preserved as newlines inside the cue |
| Cue numbering | Auto-generated sequentially (1, 2, 3...) |
| Italic / bold spans | Converted to <i> / <b> tags (SRT 1.x extension; most players honor) |
| Colors, fonts, positions | Discarded — SRT has no equivalent |
| Multiple regions / speakers | Flattened into a single text block per cue |
| Ruby annotations, furigana | Discarded — collapsed to base text |
Metadata, <head> blocks |
Discarded |
xml:lang tracks |
One language extracted per output file |
Yes — and that's intentional. SRT has no concept of position, color, font, or region, so any of those attributes from a Netflix IMSC1.1 file will be stripped. Dialogue text and timing are preserved exactly. If you need to keep styling, convert to WebVTT instead (.vtt keeps positioning and basic CSS) or to ASS/SSA (full styling including fonts and colors).
TTML supports tick-based timestamps (<p begin="500t" ...>) where the tick rate is declared in the file header via ttp:tickRate. The converter reads the declared tick rate and converts each tick value to seconds, then to SRT's millisecond format. If a file omits tickRate, the W3C default of 1 tick per second is assumed. This is the single most common cause of TTML→SRT drift bugs (see SubtitleEdit issue #2334) — our parser handles all three TTML time forms: clock-time, offset-time, and ticks.
Two likely causes. First, frame-rate mismatch: a 23.976 fps source captioned for 25 fps PAL will drift increasingly over the runtime. The fix is FPS retiming, not a constant shift — drift grows linearly. Second, an embedded ttp:timeBase of "media" vs "smpte" can introduce a fixed offset (typically the SMPTE non-drop-frame head). If your shift is constant from start to finish, open the SRT in Subtitle Edit and apply a global time offset; if it grows, run an FPS conversion.
Yes — both services ship IMSC1.1 (Netflix mandates it; Disney+ follows the same profile). Upload the .xml or .ttml file as you'd receive it from the player's debug menu or a tool like widevine-l3-decryptor + N_m3u8DL-RE. The converter handles Netflix's region-based positioning by flattening to plain text and discards Netflix-specific xml:id metadata. Note: you must have legal rights to the captions; we don't endorse circumventing DRM.
DFXP (Distribution Format Exchange Profile) was the original W3C profile name for TTML — it's effectively a synonym for "TTML 1.0 with a specific profile". IMSC (Internet Media Subtitles and Captions) is the modern W3C profile family used by streaming: IMSC1.1 is the current Netflix requirement; IMSC1.3 is the latest spec (W3C Recommendation, May 2026), superseding IMSC1.2 (August 2020). The converter accepts all three — DFXP, plain TTML, and any IMSC profile — and produces standard SRT output.
Italic and bold spans in TTML (tts:fontStyle="italic", tts:fontWeight="bold") are converted to <i>...</i> and <b>...</b> tags in the SRT output. These are extensions to the original SubRip spec but are honored by VLC, MPV, Plex, Jellyfin, mpv-player, and most modern players. If your target player is strictly plain-text (some hardware media players from before 2015), open the SRT in any editor and strip the tags.
A single TTML file with multiple <div xml:lang="..."> blocks produces one SRT per language. Upload the file once and the converter detects available language tracks; pick one or export them all. If you need both languages in the same display, that's a "dual subtitle" workflow — convert each language separately, then merge using a tool like Subtitle Edit's "Append" feature or a side-by-side script.
Yes. YouTube accepts SRT files via Studio → Subtitles → Upload file, and Vimeo accepts them through the captions panel on each video. Both platforms reparse the SRT into their internal caption format, so any italic/bold tags will display correctly on YouTube but may be stripped on Vimeo. For YouTube, the file must be UTF-8 encoded (the default here) — Windows-1252 SRTs from older tools will mangle accented characters.
Yes. The entire conversion runs in your browser via JavaScript — no upload, no server roundtrip. Once the page loads, you can disconnect from the internet and keep converting. This also means files of any size work (we've tested with 2-hour film TTMLs over 5 MB), since you're not bottlenecked by upload bandwidth.