TTML to CSV
Or paste subtitle text
What this conversion changes
3 things are dropped or need a decision
- Styling
all styling (bold, italic, colour, outline, shadow)
- Positioning
on-screen positioning (every cue returns to the default position)
- Format-specific content
content the source format keeps outside its cues (non-cue blocks, header text, per-cue settings, commented-out events) — the target format has no place for it
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 TTML to CSV. Drop a file in — or paste the text — and you get the CSV version back. The conversion runs entirely in your browser, so nothing is uploaded and no account is needed.
These two formats do not store the same things, and the difference is not cosmetic: styling, positioning and format-specific content have nowhere to go in CSV. The list above comes from what the two formats can each express rather than from your file, so it is the same answer before you load anything.
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 TTML file, converted to CSV
Input
<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling" xml:lang="en">
<head>
<styling>
<style xml:id="s1" tts:color="#FFFF00" tts:fontWeight="bold"/>
</styling>
<layout>
<region xml:id="bottom" tts:origin="10% 80%" tts:extent="80% 20%"/>
</layout>
</head>
<body>
<div>
<p begin="00:00:01.000" end="00:00:03.500" region="bottom" style="s1">Hello <span tts:fontStyle="italic">there</span>.</p>
<p begin="00:00:03.500" end="00:00:06.000" region="bottom">How are you?<br/>Fine, thanks.</p>
</div>
</body>
</tt>
Output
start,end,text
00:00:01.000,00:00:03.500,Hello <i>there</i>.
00:00:03.500,00:00:06.000,"How are you?
Fine, thanks."
Dropped in this output: styling, positioning and format-specific content. Everything else matches line for line.
The same conversion on an awkward input
Input
<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
ttp:frameRate="25" xml:lang="en">
<body>
<div>
<p begin="1.5s" dur="2s">Loaded from an offset and a duration.</p>
<p begin="4s" end="00:00:06.50">A coarser clock spelling.</p>
<p begin="00:00:07:00" end="00:00:08:12">Frames, at 25fps.</p>
<p begin="9s"><span tts:color="#FF0000">Half-open</span> and Tom & Jerry.</p>
</div>
</body>
</tt>
Output
start,end,text
00:00:01.500,00:00:03.500,Loaded from an offset and a duration.
00:00:04.000,00:00:06.500,A coarser clock spelling.
00:00:07.000,00:00:08.480,"Frames, at 25fps."
00:00:09.000,00:00:11.000,"<font color=""#FF0000"">Half-open</font> and Tom & Jerry."
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
Do bold and italic survive from TTML into CSV?
Emphasis does; the style table does not. Formatting that belongs to a piece of text — bold, italic, underline, a colour — is written into the CSV text as tags (`<i>`, `<b>`, `<u>`, `<font color="…">`), because that is the one kind of styling a cue-level format can still carry. What is lost is everything the TTML file said globally: the font, its size, the outline, the shadow and the margins.
What happens to the on-screen position from TTML to CSV?
CSV cannot say where a subtitle is drawn, so the `region` and `style` references a `<p>` carries are dropped on the way out of TTML, and every cue goes back to the default position the player chooses — the bottom of the frame, centred, for most of them.
What happens to the TTML prolog, its `<styling>` and `<layout>` tables in CSV?
Dropped. A TTML file keeps its look and its layout in the head rather than in the words: the XML declaration and its namespace bindings, the `<styling>` table of named styles (`tts:color`, `tts:fontWeight`), the `<layout>` table of named regions (`tts:origin`, `tts:extent`), any `<metadata>`, and the `style` / `region` attributes a `<p>` uses to point at them. CSV stores cues, not a document, so nothing in that head has a place to land. Styling written *inside* a paragraph is a different matter — a `<span tts:fontStyle="italic">` is emphasis on the words, and it is written out in CSV's own markup wherever CSV has any.
What does the output look like when TTML becomes CSV?
Like CSV: a header row (`start,end,text`) and then one row per cue. Every TTML cue becomes one CSV cue, in the same order, with the same text.
Are the TTML timings exact in the CSV file?
Yes, to the millisecond — which is as fine as either format goes. Both TTML and CSV write a moment the same way, `00:00:04.126`, so the timecodes come out character for character as they went in.
How does a two-line TTML cue come out in CSV?
As two lines inside the one text cell, quoted the way CSV requires. The pairing survives — the two TTML lines still belong to one subtitle in the CSV output, and a player shows them together.
Do TTML cues keep their order in the CSV 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 TTML file listed its cues out of sequence, the CSV 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 CSV back to TTML?
Yes, and that direction costs nothing: a CSV file holds less than TTML can, so nothing further is dropped on the way back. What this direction dropped stays dropped, though — styling, positioning and format-specific content cannot be rebuilt from a CSV file, because nothing in it records what they were.
Does the CSV output keep the TTML file's encoding?
No — the output is UTF-8, with Unix line endings and no byte-order mark, whatever the TTML 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 CSV.