SRT vs VTT vs TTML: Three Formats, Three Jobs
Summarize this article with:
Three Formats, Three Jobs
SRT is for portability, VTT is for the web, TTML is for broadcast and OTT delivery. If you have ever uploaded a caption file and watched it silently fail, you have run into this mismatch. The three formats look similar from the outside but solve different problems, and most platforms only accept one or two.
This post maps each format to its real-world job: what it looks like structurally, which players and platforms accept it, and where the OTT delivery specs diverge in ways that matter if your content ends up on Netflix, Amazon, or Disney+. For the simpler two-format choice between SRT and WebVTT, the SRT vs VTT comparison goes deeper without the broadcast context.
SRT: The Lowest Common Denominator
SRT (SubRip) is the oldest of the three and the most widely supported format in existence. A bare SRT file looks like this:
1
00:00:01,000 --> 00:00:04,500
This is the first caption.
2
00:00:05,000 --> 00:00:08,200
This is the second caption.
Each block has a sequence number, a timecode range using a comma as the millisecond separator, and one or two lines of text. That comma is not accidental: SRT was created in Europe, where the comma is the decimal separator. When people convert SRT to VTT by hand and forget to swap commas to periods, the file fails silently in browsers.
The strengths of SRT are inseparable from its limits. The format is so plain that every video player on every operating system reads it: YouTube, Vimeo, VLC, Plex, Premiere Pro, DaVinci Resolve, and most broadcast-grade encoders. If you can only ship one format, ship SRT.
The weaknesses are the lack of native styling and the one-language-per-file constraint. If you need bold text, color, screen positioning, or speaker attribution in the caption data itself, SRT cannot carry that. Most workflows that need styled captions burn the text into the video pixels, which the subtitle generator guide covers separately.
VTT: The Modern Web Standard
WebVTT is the format the W3C built for HTML5 video, and it is the one every modern browser understands natively. The structure parallels SRT but uses a period as the millisecond separator and ships with explicit support for styling, positioning, and speaker metadata:
WEBVTT
00:00:01.000 --> 00:00:04.500 line:90% align:center
<v Alice>This is the first caption.
00:00:05.000 --> 00:00:08.200
<v Bob>This is the second caption.
The <v Alice> and <v Bob> tags are speaker voice annotations, which means a VTT file can carry diarization data out of the box. The line:90% align:center cue settings tell the player where on screen to render the text. You can also attach CSS via the ::cue pseudo-element for color, font size, and background.
VTT is required if you use the HTML5 <track> element to attach captions to a <video> tag on your own site. Every modern browser reads it natively. JavaScript players like Video.js and Plyr are built around VTT. If you are publishing web video, this is the format you want.
Where VTT runs into trouble is non-web destinations. YouTube does accept VTT (along with SRT, SBV, TTML, and DFXP), but most consumer encoders and broadcast tools default to SRT or require TTML. Convert from whichever format you generated first; the timecode swap is the only technical lift.
TTML: The Broadcast and OTT Format
TTML (Timed Text Markup Language) is what major streaming services and broadcasters require on delivery, and it is not interchangeable with SRT or VTT for those destinations. The file is XML and looks dramatically heavier than the other two:
<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml"
xmlns:tts="http://www.w3.org/ns/ttml#styling">
<head>
<styling>
<style xml:id="default"
tts:fontFamily="sansSerif"
tts:color="white"
tts:fontSize="100%"/>
</styling>
</head>
<body>
<div>
<p begin="00:00:01.000" end="00:00:04.500"
style="default">This is the first caption.</p>
<p begin="00:00:05.000" end="00:00:08.200"
style="default">This is the second caption.</p>
</div>
</body>
</tt>
That verbosity buys real capability: rich styling, multiple language tracks in a single file, percentage-based positioning, ruby text for Japanese, and structured metadata for accessibility auditors. TTML is a W3C spec, but in practice every platform that requires it uses a specific profile.
The OTT Profiles: Netflix, Amazon, Disney+
This is where "TTML" stops being a single answer. The major streamers each mandate a different profile or set of constraints.
Netflix requires TTML1 with a .xml or .ttml file extension for all languages. Japanese is the exception: Netflix requires IMSC 1.1 format for Japanese specifically, with its own profile identifier. The general TTML1 requirements are strict: all positional data must use percentage values only, never pixels; font size must be expressed as 100%; timecodes depend on the frame rate of the source.
Amazon Prime Video is more permissive than Netflix. For captions, it accepts STL, DFXP/TTML, SCC, and SRT. For subtitle files (dialogue-only), it accepts DFXP/TTML, iTT (a TTML 1.0 subset Apple developed), and SRT. The SRT acceptance on the subtitle track means many smaller producers can bypass TTML entirely for Prime Video Direct submissions.
Disney+ requires IMSC 1.1 as its general delivery format. For Japanese content it publishes its own IMSC 1.1 profile with separate validation rules.
EBU-TT-D is the profile the European Broadcasting Union developed for IP distribution and DVB-DASH streaming. It is a subset of the IMSC 1 Text Profile, with minor differences. The UK's Freely platform (the joint BBC/ITV/Channel 4/Channel 5 IPTV service launched in 2024) mandates EBU-TT-D for all participating players. If a contract mentions "EBU-TT-D," it is asking for a constrained TTML file, not a wholly different format.
My take: if you are not delivering to a broadcaster or named OTT platform, you almost certainly do not need TTML. The format's complexity is a cost that only pays off when a specific spec demands it. Outside of those contracts, the rest of the industry is well served by SRT and VTT.
Feature Comparison Table
| Feature | SRT | VTT | TTML |
|---|---|---|---|
| File extension | .srt | .vtt | .ttml or .xml or .dfxp |
| Millisecond separator | Comma (,) | Period (.) | Period (.) |
| Player support | Universal | Modern browsers, web players | Broadcast and OTT tools |
| Styling | None (some players honor inline HTML tags) | CSS via ::cue | Rich, attribute-based |
| Speaker labels | No (workarounds only) | Yes, via <v Name> tags | Yes, multiple mechanisms |
| Positioning | No | Yes, percentage-based cue settings | Yes, pixel-precise or percentage |
| Multiple languages | One file per language | One file per language | Multiple in one file |
| OTT delivery | No | No | Yes, via platform-specific profiles |
| Primary use case | Universal portability | HTML5 web video | Broadcast, OTT, compliance |
The tiering is practical: SRT for the widest reach, VTT for HTML5 video, TTML when a contract names a specific profile.
Conversion: What You Lose in Each Direction
Converting between the three formats is mostly mechanical, but the conversion is not symmetrical.
SRT to VTT is nearly lossless. Add a WEBVTT header on the first line and change all comma separators in timecodes to periods. The block structure stays identical. If you want speaker labels, add <v Name> annotations by hand or from a diarized transcript source.
SRT or VTT to TTML adds structure you then need to populate. The timecodes transfer cleanly. The styling attributes are either blank (requiring a localization engineer to fill in) or auto-populated by a conversion tool. The platform profile is almost never handled by generic converters: you will need to add the profile designator, the percentage-only font sizes, and any frame-rate timecode mode the spec requires. Plan for a QC pass after any TTML conversion.
TTML to SRT is lossy. Styling, positioning, and multi-language tracks all drop. The resulting SRT will have plain text with correct timecodes, which is often exactly what a YouTube upload needs.
A timing pitfall worth naming: TTML conversions sometimes strip millisecond precision when the source uses different frame rate timecode modes (SMPTE vs media time). If captions feel one frame off after conversion, the timecode mode is the cause, not the content.
The two most common scenarios in practice:
- A client delivers an SRT and your broadcaster requires TTML for a delivery spec. Convert, then add the required metadata fields and validate against the spec. The subtitle generator can produce SRT from audio if you need to start from scratch.
- A broadcaster delivers a TTML and you need SRT for a YouTube upload or web player. Convert and accept the styling loss. The text and timing will be correct.
Platform Reality Check
Here is what each major destination actually accepts, verified against current platform documentation:
- YouTube: SRT, VTT, SBV, TTML, DFXP, SCC, and several legacy broadcast formats via YouTube Studio.
- Vimeo: SRT and VTT.
- Facebook and Instagram: SRT only via creator upload tools. Most short-form content burns captions into the video.
- TikTok: No external caption file upload. Burn into video.
- Netflix: TTML1 (.xml/.ttml) for all languages; IMSC 1.1 for Japanese. All positional data must use percentage values only.
- Amazon Prime Video: DFXP/TTML, iTT, and SRT for subtitle tracks.
- Disney+: IMSC 1.1.
- European broadcast / DVB-DASH: EBU-TT-D (a constrained TTML subset).
- HTML5 video on your own site: VTT via the
<track>element.
If you publish to more than one destination, generate a clean SRT first and convert downstream. Editing XML by hand is slow; editing a plain-text SRT and reconverting takes seconds.
Picking the Right Starting Format
For the majority of use cases, generate SRT first. You can export SRT directly from any transcription, edit errors in a plain text editor, upload to YouTube, and attach to a video file. If your destination is an HTML5 player on your own site, switch the export to VTT. If a broadcaster or OTT platform is in the delivery chain, convert from your SRT source once you have confirmed the exact profile the spec requires.
The format is rarely the bottleneck. Accuracy, readable line breaks, and correct timing are what viewers notice. Once those are right, format conversion is a step measured in seconds. ConvertAudioToText generates SRT and VTT directly from any audio or video file, giving you a clean source to work from. For TTML delivery, use that SRT as the conversion input rather than converting from a rough draft.
Common Questions
What is the difference between SRT and VTT?
SRT uses a comma as the millisecond separator in timecodes (00:00:01,000) and has no header line. VTT uses a period (00:00:01.000) and starts with a WEBVTT header. VTT also supports speaker voice tags, percentage-based positioning, and CSS styling. For HTML5 web video, VTT is the right choice. For maximum cross-platform compatibility, SRT reaches further. The SRT vs VTT comparison covers the two-format decision in detail.
Does Netflix require TTML or IMSC?
Netflix requires TTML1 (file extension .xml or .ttml) for all subtitle and SDH deliverables in most languages. IMSC 1.1 is required for Japanese content specifically, under Netflix's own IMSC 1.1 profile. The two are related: IMSC is a constrained TTML profile, but the naming in Netflix specs is specific. Confirm the exact profile against your current Netflix partner delivery documentation before submitting.
Can I convert SRT to TTML automatically?
Yes, but with caveats. Generic converters transfer timecodes and text accurately. They typically do not populate the platform-specific profile designator, percentage-only font sizing, or frame-rate timecode mode a particular OTT spec requires. After any automatic SRT-to-TTML conversion, a QC pass against the target spec is mandatory before delivery.
Which format should I use for YouTube?
SRT or VTT both work on YouTube. YouTube accepts both along with several other formats. SRT is the more common choice because it is the output of almost every transcription tool and is simpler to edit manually. VTT works equally well if that is what your transcription workflow produces. For YouTube subtitles specifically, the subtitle generator produces either format from an audio or video upload.
Sources
- Netflix Partner Help Center: Timed Text Style Guide General Requirements
- Netflix Partner Help Center: Netflix IMSC 1.1 Text Profile
- Amazon Prime Video Direct: Caption Requirements
- YouTube Help: Supported Subtitle and Closed Caption Files
- W3C: WebVTT: The Web Video Text Tracks Format
- W3C: TTML Profiles for Internet Media Subtitles and Captions (IMSC 1.2)
- MDN Web Docs: IMSC: Subtitles and Captioning for the Web
- DVB: DVB-TTML Subtitling Systems
Try transcription free
Convert any audio or video to clean, unwatermarked text — speaker labels, timestamps, and AI summaries included. First 30 minutes free, no account.
Related Articles
Subtitle Editor Comparison 2026: Pick by Workflow
Subtitle editors compared by workflow: desktop power tools vs web editors, and when generating beats editing.
SRT vs VTT Subtitle Formats: Which Should You Use? (2026)
A data-led comparison of SRT and VTT subtitle formats covering player support, styling, positioning, and exactly when to choose each. Updated for 2026.