SRT to TTML converter
Move a subtitle file between SRT, VTT, ASS and the TTML family — TTML 1.0 or the iTT shape — without touching the timeline. Same parse the studio uses, so the times you see are the times you get. The file never leaves your browser.
Drop an .srt / .vtt / .ass / .ttml file here
or click to choose one, or paste subtitle text anywhere on this page · the conversion appears below, nothing is uploaded
First 6 cues, as they came out
Head of the converted file
Read a TTML time expression
TTML element by element
| Element / attribute | What it is for | When you meet it |
|---|---|---|
tt | The root element. Holds the TTML namespaces and, in practice, the document's timing properties. | Every TTML file — it is the document. |
head | Everything that is not timed text: the styling and layout definitions live here. | Whenever the file defines a font, a colour or a screen position. |
body | The timed-text container. Can set a default style or region for everything inside it. | Every TTML file, directly under tt. |
div | A grouping level between body and the paragraphs. The iTT shape uses one div per cue. | Always; the count only differs between flavours. |
p | One paragraph = one subtitle cue. Carries the times and the text. | Once per cue. |
begin, end | When the paragraph appears and disappears, on the media timeline. | On nearly every p. end may be replaced by dur. |
dur | The length of the cue instead of an absolute stop time. | Files written by a script, where a duration is easier to emit than an end time. |
region | A named rectangle on screen, defined by an origin and an extent; a p that names one is positioned by it. | Whenever the delivery asks for a fixed position rather than the player's default. |
style | A named bundle of presentation attributes (font, colour, alignment) that paragraphs reference. | When styling has to travel inside the file instead of being re-applied by the player. |
br, span | A line break inside a paragraph, and inline styling within a line. | Two-line cues — this converter writes <br/> between the lines of a cue. |
ttp:timeBase | How the times in the document are counted. media means a timecode on the media timeline. | On the tt element; this converter always writes media. |
Namespaces used here: ttml for the elements, tts for styling,
ttp for parameters. A file that mixes them up is still readable by a tolerant parser, which is
why the studio's parser recovers what it can and reports the rest instead of refusing the file.
The three ways TTML can write a time
| Form | Example | Reads as | When you meet it |
|---|---|---|---|
| clock-time | 00:00:04.500 | 4500 ms | Almost every delivery file. Hours, minutes, seconds and a decimal fraction written with a dot. |
| offset-time | 4s · 250ms · 1.5m | 4000 · 250 · 90000 ms | Machine-written files, and nearly always on dur rather than end. Units are h m s ms, plus f for frames and t for ticks. |
| frame number | 00:00:02:12 | 2480 ms at ttp:frameRate="25" | Files handed over from the broadcast side, where positions are counted in frames. The rate must be declared in the file, or the time cannot be converted at all. |
| ticks | 100t | 1 ms at ttp:tickRate="100000" | Rare; a hardware-clock unit from the broadcast world. Same rule as frames: without the declared rate the number means nothing. |
The reader above answers these live. A comma as the decimal separator — the SRT convention — is not a TTML clock-time and is rejected rather than quietly rewritten, because the studio's parser would skip such a value on the way in. Frames and ticks refuse to convert when the rate is missing rather than assuming 25 fps or any other default: a silently wrong rate moves the whole file, and the result still looks plausible in a player.
What this export is, and what it is not
| What you get | Detail |
|---|---|
| A well-formed TTML 1.0 document | XML declaration, a tt root with the TTML namespaces, head with one style and one bottom region, and one p per cue carrying begin and end. The iTT output uses the common one-div-per-cue shape. |
| Timings and text carried over exactly | No shift, no stretch, no rounding beyond the millisecond the source already had. Styling tags in the source ({\...} overrides in ASS, classes in VTT) are removed, not translated. |
| No certification claim | There is no profile declaration in the output, no check against any broadcaster's or platform's delivery specification, and the style set is deliberately minimal — one plain bottom region. Those specifications exist, they differ between recipients, and they are not something a free browser page can sign off on. |
| What it does not do | It does not re-time, split, merge or re-wrap cues, does not convert between frame rates, and does not keep the source's styling. Those are separate jobs (and separate tools below). |
Why TTML turns up in delivery chains anyway
| Reason | The mechanism behind it |
|---|---|
| It is XML, so normal XML tooling works on it | A TTML file can be validated against a schema, queried with XPath, transformed with XSLT and diffed line by line. An SRT file is text with no structure to address, which is why automated checks on it end up being regular expressions. |
| Styling and position can travel inside the file | A TTML document has somewhere to put a named style and a named region, and paragraphs reference them. SRT has nowhere to put either, and VTT's styling is CSS that only a WebVTT renderer applies. When a deliverable has to pin a font or a position, that requirement tends to be expressed in TTML. |
| It is the container the receiving side asked for | Broadcast and streaming delivery specifications are written around TTML. When the answer to "which format?" is TTML and your working copy is SRT, the job is exactly this page: change the container, keep the timeline, then fix style and position in the tool that owns them. |
Converting a folder, or a season?
The studio opens many files at once, applies shift, stretch or a frame-rate correction, then hands everything back as one ZIP. Pro is a $9 one-time licence — lifetime, up to 3 devices — with a 7-day refund while the key is unactivated. Single-file conversion on this page stays free.
Questions people ask before using it
What is the difference between SRT and TTML?
SRT is plain text: a cue number, a start and stop timecode on one line, then the lines of text. TTML is an
XML document: one <p> element per cue with the times in begin and
end attributes — and room inside the same file for styling and screen regions. Both carry a start
and a stop for every cue, which is why moving between them does not require re-timing.
Why does my player not read the TTML file?
Because reading TTML is a feature of the player, not of the file. A browser's built-in video
element with a track element takes WebVTT only — that is the format the HTML specification defines
for track. TTML needs a player that ships a TTML renderer, which is what broadcast and streaming
playback chains do. Check the player's supported formats before assuming the file is broken; converting back to
SRT or VTT on this page is always available as a way out.
Does converting change the timeline?
No. The file is parsed into cues and written out in the target container, so every start and end value is the same number of milliseconds it was before; a round trip from SRT to TTML and back to SRT returns the original times and text. What does change: cue numbering is regenerated, timecode punctuation follows the target format, the output is UTF-8, and styling in the source is not translated.