Skip to main content
SubtitleMatrix

SRT to TTML

Format conversionSubRip (SRT)
Or paste subtitle text

What this conversion changes

Nothing is lost in this direction — every feature of the source format has somewhere to go in the target format.

This list comes from the capability matrix for these two formats, not from the particular file you loaded. A specific file may lose more if it uses features the format allows but the matrix does not model.

This page converts SRT to TTML. Drop a file in — or paste the text — and you get the TTML version back. The conversion runs entirely in your browser, so nothing is uploaded and no account is needed.

Nothing is lost in this direction. Every feature SRT can express has an equivalent in TTML, so the output is the same subtitles in a different wrapper — the timeline, the line breaks and the text all survive. That holds for any SRT file, including one that uses every feature the format allows.

One file is fine, and so is a whole season: the queue works through them in order and the results come down together as a single ZIP.

Examples

A typical SRT file, converted to TTML

Input

1
00:00:01,000 --> 00:00:03,500
Hello there.

2
00:00:03,500 --> 00:00:06,000
<i>Whispering</i> now.
And a second line.

3
00:00:06,000 --> 00:00:09,250
<b>Bold</b> statement.

Output

<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling">
  <body>
<p begin="00:00:01.000" end="00:00:03.500">Hello there.</p>
<p begin="00:00:03.500" end="00:00:06.000"><span tts:fontStyle="italic">Whispering</span> now.<br/>And a second line.</p>
<p begin="00:00:06.000" end="00:00:09.250"><span tts:fontWeight="bold">Bold</span> statement.</p>  </body>
</tt>

Nothing is dropped here: compare the two sides line for line.

The same conversion on an awkward input

Input

1
0:00:01,00 --> 0:00:03,500
<B>Bold</B> and <I>italic</I>.


2
00:00:03,500 --> 00:00:06,000


3
00:00:08,000 --> 00:00:09,000
Last one.

Output

<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling">
  <body>
<p begin="00:00:01.000" end="00:00:03.500"><span tts:fontWeight="bold">Bold</span> and <span tts:fontStyle="italic">italic</span>.</p>
<p begin="00:00:03.500" end="00:00:06.000"></p>
<p begin="00:00:08.000" end="00:00:09.000">Last one.</p>  </body>
</tt>

This is the kind of damage real files have — mixed line endings, stray whitespace, fields left empty. Compare it with the tidy example above to see what the parser forgives.

Frequently asked questions

What does the output look like when SRT becomes TTML?

Like TTML: no cue numbers: every subtitle is a `<p>` element with `begin` and `end` attributes, nested in a `<body>` (and usually a `<div>`), with an XML declaration above the whole document. Every SRT cue becomes one TTML cue, in the same order, with the same text.

Are the SRT timings exact in the TTML file?

Yes, to the millisecond — which is as fine as either format goes. SRT writes a moment as `00:00:04,126` and TTML writes the same moment as `00:00:04.126`; nothing is rounded or shifted between the two, and a cue that was on screen for 2.9 seconds still is.

How does a two-line SRT cue come out in TTML?

As two lines with a `<br/>` between them, which is how TTML writes a hard line break. The pairing survives — the two SRT lines still belong to one subtitle in the TTML output, and a player shows them together.

Do SRT cues keep their order in the TTML output?

Yes, and they are sorted by start time on the way — earliest first, which is how every format here expects them and how players read them. If your SRT file listed its cues out of sequence, the TTML output puts them back in order; that is a change to the file's structure rather than its content, and it is deliberate.

Can I convert the TTML back to SRT?

Yes, and that is the lossy direction: styling, positioning and format-specific content have nowhere to go in SRT. This way round nothing is lost, so that cost only appears if you go back.

Does the TTML output keep the SRT file's encoding?

No — the output is UTF-8, with Unix line endings and no byte-order mark, whatever the SRT file used. A file that arrives in UTF-16, or in a Windows single-byte encoding, is decoded on the way in (the result panel says so when that happens); what comes out is always the same UTF-8 TTML.

Related tools