Home › Guides

Subtitle formats explained: SRT, WebVTT, TTML/IMSC, EBU-TT-D, STL, SCC and PAC, and which one your buyer actually wants

By the Fonti Studio post-production team · 12 August 2026

A delivery schedule asks for "subtitles in IMSC 1.1 and EBU-TT-D, plus an SRT for reference." Somebody sends the SRT, converts it with whatever tool comes up first, and the package bounces. The translation was fine. The formats were the problem.

Subtitle formats look interchangeable because they all hold the same three things: a start time, an end time, and some text. They are not interchangeable, and the differences that matter are not cosmetic. This is the working map: what each format is, where it came from, what it can and cannot express, and the one distinction that causes more failed deliveries than everything else combined.

The distinction that breaks deliveries: time versus frames

Before the formats, the fault line running through them.

Some formats store real clock time. SRT stores 00:01:23,440: one hour, twenty-three seconds, four hundred forty milliseconds of actual elapsed time. WebVTT does the same with a period instead of a comma. These files carry no frame rate, and they do not need one. Play them against a 23.976 fps master or a 25 fps master and the text appears at the same wall-clock moment either way.

Some formats store frames. EBU STL, SCC, and Screen PAC store timecode: hours, minutes, seconds, and a frame number. A frame number is meaningless without knowing how many frames make a second. The same file interpreted at 24 fps and at 23.976 fps produces different real times, and the divergence grows across the runtime.

Every conversion between the two halves needs the true frame rate of the video as an input. Get it wrong and the file drifts: perfectly synced at the head, seconds off by the climax, which is precisely the most common way a professionally produced subtitle delivery fails QC. Whenever you hand a vendor a frame-based deliverable, the frame rate should be stated in the delivery notes, and it should be the measured rate of the master, not the assumed one.

The formats, in the order you will meet them

SRT (SubRip)

The lingua franca. A numbered cue, a timing line, one or two lines of text, a blank line, repeat. No official standard body, no schema, just a convention that everything on earth can read and write.

SRT stores milliseconds, so it is frame-rate agnostic and safe to hand around. What it cannot express is nearly everything else: no positioning (beyond a de facto {\an8} hack), no region model, no styling beyond basic <i> italics that some parsers honour and others print literally, no metadata, no language declaration. It is a text interchange format, and it is excellent at that job.

Use it as: the master you author from, the reference copy in every delivery, the file you send someone to eyeball. Do not use it as: the deliverable a broadcast or streaming platform ingests, unless they explicitly ask for it.

WebVTT (.vtt)

The web's native format, standardised by the W3C for HTML5 video and the <track> element. Structurally similar to SRT (it even accepts the same shape of cue) with a WEBVTT header, optional cue identifiers, and real capabilities SRT lacks: cue settings for position, line, size and alignment, a CSS-based styling model, regions, and comments.

WebVTT also stores real time, so converting between SRT and VTT is lossless on timing and needs no frame rate. If your content plays in a browser, a player SDK, or a modern OTT app, VTT is usually what the front end wants.

TTML, and the IMSC profiles

TTML (Timed Text Markup Language) is the XML-based W3C standard that professional timed text is built on. It is powerful and correspondingly large: styling, layout, regions, timing containers, metadata, multiple languages in one document.

Because "TTML" alone is too broad to interoperate against, the industry uses profiles: constrained subsets everyone agrees to implement. IMSC 1.1 (TTML Profiles for Internet Media Subtitles and Captions) is the W3C Recommendation that matters for streaming delivery, defining a text profile and an image profile for worldwide subtitle and caption delivery. IMSC 1.2 exists and remains compatible with 1.1 documents.

You will also see DFXP, an older name for the TTML flavour used in the Distribution Format Exchange Profile, and SMPTE-TT. Treat them as historical labels in the same family; what a modern platform wants is a conformant IMSC document.

The trap here is subtle and expensive: a file can be valid XML, parse as TTML, and still fail a platform's conformance check because it uses a style attribute outside the profile, orders elements wrongly, or declares namespaces the profile does not permit. Conformant TTML is not "an SRT with angle brackets," and a converter that treats it that way produces files that look fine locally and bounce on ingest.

EBU-TT-D

The European Broadcasting Union's distribution profile of TTML, defined in EBU Tech 3350. It is what European broadcasters and their platforms ask for when they want XML timed text: a constrained TTML profile aimed at IP distribution, with its own region and styling conventions. If a buyer in Europe asks for "EBU-TT-D," they mean this document's profile specifically, not TTML in general.

EBU STL (.stl)

The veteran. EBU Tech 3264, published in 1991, defines a binary subtitle exchange file with a general subtitle information block and a fixed-size record per subtitle. It is still everywhere in European broadcast because decades of infrastructure read and write it.

STL is frame-based, it carries its own frame-rate field, and it is character-set constrained in ways that surprise people the first time an accented character or a typographic apostrophe disappears. When a broadcaster asks for STL, ask which frame rate and which code page.

SCC (Scenarist Closed Captions)

The North American broadcast caption format: a text file of timecodes plus hexadecimal byte pairs that are literally CEA-608 caption control codes. It is frame-based, drop-frame aware, and it encodes caption behaviour (pop-on, roll-up, paint-on) rather than just text.

SCC is not a subtitle file with a different extension; it is a caption stream serialised to text, which is why converting to it faithfully is a real engineering job and why a naive SRT-to-SCC conversion produces something that technically imports and behaves wrongly on air.

Screen PAC (.pac) and friends

The binary format of the Screen Electronics / Polistream authoring world, along with its siblings from other subtitling houses (Spruce STL, Cavena, EZTitles' own formats). Professional subtitling clients in Europe frequently author and deliver in PAC, so if you are servicing a title for a broadcast subtitling house, this is often what lands in your inbox alongside the SRT.

PAC is frame-based, binary, and has its own text encoding with prefix codes for accented characters. VLC will not open it. Subtitle Edit will. Two practical warnings from files we have had to rescue: a PAC written at the wrong frame rate produces the linear drift described above, and a PAC encoder with no code point for the typographic apostrophe (’) can silently drop it, turning "Orka's" into "Orkas" while the SRT beside it looks perfect.

Which format your buyer actually wants

The rule that keeps deliveries clean: author once, in a format that stores real time and full text fidelity, and generate every frame-based deliverable from that master at the measured frame rate. Never convert a conversion. Every hop through a frame-based format is an opportunity to bake in an fps assumption that nobody wrote down.

That is how our pipeline is built: one internal cue representation holds the timing in milliseconds and the text with its formatting, and SRT, TTML, IMSC 1.1, EBU-TT-D, CEA-608/708 and PAC all render from it deterministically, each validated against its own format rules before delivery. On our reference delivery, The Last Kumite (2024) in French and Dutch, that produced zero errors against the Netflix Branded Delivery subtitle spec across 1,212 cues per language.

Common questions

What is an SRT file?

A plain-text subtitle file in the SubRip format: numbered cues, each with a start and end time in hours, minutes, seconds and milliseconds, followed by the subtitle text. It stores real clock time rather than frames, carries almost no styling or positioning information, and is readable by nearly every player and editing tool, which is why it is the industry's default interchange format.

What is the difference between SRT and VTT?

Both store real clock time and look similar, but WebVTT is a W3C standard built for HTML5 video, with a WEBVTT header, a period instead of a comma in timestamps, and real support for positioning, styling and regions that SRT lacks. Converting between them is lossless on timing and needs no frame rate; you can do it in the browser here.

What is IMSC, and how is it different from TTML?

TTML is the broad W3C XML standard for timed text. IMSC is a constrained profile of it, published as a W3C Recommendation, that platforms actually implement, so files interoperate. A document can be valid TTML and still fail an IMSC conformance check, which is the usual reason a converted file bounces at ingest.

Which subtitle format does a frame rate matter for?

The frame-based ones: EBU STL, SCC, and Screen PAC store timecode with frame numbers, so they must be generated and read at the video's true frame rate. SRT, WebVTT and TTML/IMSC store real time and are frame-rate agnostic. Mixing the two halves at the wrong rate is what causes subtitles that drift progressively out of sync.

Can I just convert my SRT to whatever the buyer asked for?

For VTT, yes, it is a clean mapping. For IMSC, EBU-TT-D, SCC or PAC, a naive conversion produces a file that opens locally and fails on ingest, because those formats encode conformance rules, caption behaviour, character sets and frame rates that an SRT does not contain. Those deliverables should be generated from a properly authored master, with the frame rate stated.

What to put in your delivery brief

Name the formats explicitly, state the measured frame rate of the master, and ask for the reference SRT alongside whatever else you need, because it is the copy anyone can open. If a buyer's schedule uses a term you do not recognise, it is almost always one of the families above wearing a house name.

Fonti Studio delivers SRT by default and TTML, IMSC 1.1, EBU-TT-D, CEA-608/708 and PAC on request, generated from one master at your video's measured frame rate and validated per format before it ships. Free browser tools for the everyday conversions are here; for a delivery that has to pass someone else's QC, email us the brief.

Fonti Studio is a subtitle and dubbing studio run by post-production engineers, for film distributors and sales agents. €400 per language for feature subtitles, every delivery format included. Flat. EUR. Free preview before you pay.