SRT vs VTT vs iTT: which subtitle format do you need?

SRT, VTT, and iTT are the three subtitle formats an editor most often has to choose between, and the choice is really about destination: SRT is the universal interchange format nearly everything accepts, VTT (WebVTT) is the web standard browsers and HTML5 players require, and iTT (iTunes Timed Text) is Apple's delivery spec for the iTunes Store and Apple TV. Same captions, three different containers — this guide covers what actually differs (timing syntax, styling, frame-rate handling), which one each destination wants, and how to convert between them without breaking timing.

The one-paragraph version of each

SRT (SubRip, `.srt`) — the plain-text veteran: numbered cues, 00:01:02,500 timestamps (comma before the milliseconds), a blank line between cues, and essentially no styling beyond basic italic/bold tags that some players honor. Its power is universality: NLEs, players, YouTube, and every subtitle tool read it.

VTT (WebVTT, `.vtt`) — the W3C web standard, and what the HTML5 <track> element requires. It looks like SRT with a WEBVTT header and dots instead of commas (00:01:02.500), then adds web-native features: cue positioning, alignment, per-cue styling with CSS, voice tags for speakers, and metadata notes.

iTT (iTunes Timed Text, `.itt`) — Apple's delivery format, an XML dialect (a constrained profile of TTML) used for subtitle delivery to the iTunes Store and in Final Cut Pro workflows. Unlike SRT and VTT, iTT is frame-rate aware: the document declares its frame rate and times can resolve to frames, which is why Apple specs it for film/TV delivery, and why converting to it requires knowing your video's frame rate.

What actually differs

Two of these differences cause almost all real-world breakage. The comma/dot swap between SRT and VTT means a file with the wrong separator gets rejected by strict parsers — the classic "why won't my SRT work" bug. And iTT's frame-rate declaration means an .itt made for 23.976 video is wrong for a 25 fps master in a way SRT and VTT can't even express — always convert with the target frame rate in hand.

Which format does your destination want?

• YouTube, Vimeo, social platforms → SRT (all accept it; most also take VTT)
• A website's own video player → VTT, no exceptions — browsers only render WebVTT tracks
• iTunes Store / Apple TV delivery → iTT, per Apple's delivery spec
• Final Cut Pro captions → iTT imports as a caption role (SRT also imports; iTT preserves more)
• Premiere, Resolve, Avid → SRT is the safe interchange (see the import guides)
• Broadcast delivery → none of these three — that's SCC, MCC, or STL territory

Converting between them

Because SRT carries the least, SRT→anything is clean, and anything→SRT sheds styling and positioning (usually fine — the destination re-styles anyway). The converters handle the details that trip up hand-editing:

• SRT to VTT — header, separator swap, and syntax differences handled
• VTT to SRT — web features stripped cleanly back to universal SRT
• SRT to iTT — frame-rate-aware conversion; pick the video's real frame rate (23.976 vs 24 matters)
• SRT to TTML — for platforms that want full TTML rather than Apple's iTT profile

Timing is preserved exactly in all directions; what changes is the container. If a conversion looks "off by a fraction of a second" at the end of a long file, the culprit is almost always a frame-rate mismatch on the iTT side, not the converter — redo it with the correct rate.

FAQ

What's the difference between SRT and VTT? VTT is SRT's web-standard successor: it adds a WEBVTT header, uses a dot instead of a comma in timestamps, and supports positioning, CSS styling, and speaker voice tags. Browsers only render VTT; nearly everything else accepts SRT. Converting between them is lossless for text and timing.

What is an iTT file? iTunes Timed Text — Apple's XML subtitle format (a constrained TTML profile) used for iTunes Store/Apple TV delivery and Final Cut Pro caption workflows. Unlike SRT and VTT it declares a frame rate, so conversions to iTT must specify the video's actual frame rate.

Which subtitle format should I use for the web? WebVTT. The HTML5 <track> element only renders VTT, so a website's own player needs .vtt files — convert your SRT rather than hand-editing the separators.

Why does my SRT file fail with "invalid timestamp"? Usually because it has VTT-style dots (00:01:02.500) where SRT requires commas (00:01:02,500) — the telltale sign of a hand-renamed VTT file. Run it through a converter (or the SRT validator) instead of renaming the extension.

Does converting SRT to iTT change my subtitle timing? The times are preserved, but iTT resolves them against a declared frame rate — so converting with the wrong rate (24 instead of 23.976, say) yields drift that grows over the file's duration. Convert with the actual frame rate of the master.

Can I use these formats for broadcast closed captions? No — broadcast and legacy TV delivery use SCC (CEA-608), MCC (CEA-708), or EBU-STL, which encode captions at the signal level. SRT/VTT/iTT are subtitle sidecars for players and platforms; the broadcast comparison guide covers when each of those applies.