Caption Format Reference
IMSC File Format
IMSC is the TTML profile the streaming industry standardised on. It narrows TTML down to a set of features players can be relied on to implement, and adds a handful of its own — including a second profile that carries subtitles as images rather than text.
What can an IMSC file be converted to?
A text-profile IMSC converts to TTML, DFXP, WebVTT, SRT, SCC, MCC and EBU-STL, with styling reducing as the target allows. An image-profile IMSC carries bitmaps rather than characters, so it cannot be converted to any text format without optical character recognition first.
IMSC at a glance
IMSC is defined by version and profile, and delivery specs name both. A file that satisfies IMSC 1.1 text profile may be rejected by a validator expecting IMSC 1.0, so the pairing matters more than the format name.
| Property | Value |
|---|---|
| Full name | Internet Media Subtitles and Captions |
| Extensions | .ttml, .xml |
| Specification | W3C, as a set of profiles of TTML |
| Versions in use | IMSC 1.0, IMSC 1.1 and later |
| Profiles | Text profile and image profile |
| File encoding | XML, normally UTF-8 |
| Timing model | Explicit begin and end, or begin and duration |
| Positioning | Named regions expressed as percentages of the frame |
| Styling | TTML styling, plus IMSC additions such as line gap fill and multi-row alignment |
| Forced subtitles | Signalled explicitly, so foreign-dialogue subtitles can display without captions being on |
| IMSC 1.1 additions | Ruby annotation, text combination for CJK, and high dynamic range support |
| Closed Caption Creator | Read and write |
For what IMSC adds to TTML feature by feature, and how the two profiles differ, see TTML, DFXP and IMSC explained.
What IMSC can and cannot carry
The capability list below describes the text profile, which is what most deliveries mean by IMSC. The image profile carries pre-rendered bitmaps and has an entirely different set of trade-offs.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | Text profile only. The image profile carries bitmaps |
| Explicit begin and end times | Yes | Or a begin plus a duration |
| Positioning | Yes | Named regions as percentages of the frame |
| Multiple regions on screen | Yes | Independently positioned, simultaneously |
| Text colour and background | Yes | Arbitrary colours with opacity |
| Font family and size | Yes | Requested by the file; the player decides how far to honour it |
| Forced-display subtitles | Yes | An explicit signal, not a naming convention |
| Ruby and CJK text combination | Partial | IMSC 1.1 and later only |
| High dynamic range signalling | Partial | IMSC 1.1 and later only |
| Multiple languages in one file | Yes | Possible, though most delivery specs require one language per file |
| Bitmap subtitles | Yes | Image profile only, and mutually exclusive with text |
| Frame-accurate timing | Partial | Depends on the time base the file declares |
Who asks for IMSC files?
IMSC is the default answer when a modern streaming platform publishes a subtitle specification. It is rarely used outside that world.
- Streaming and OTT platforms, which typically name a version and a profile in their delivery spec.
- Localisation vendors delivering subtitle packages for global platform releases.
- Broadcasters producing an OTT deliverable alongside a traditional playout file.
- Workflows that need forced subtitles signalled properly rather than handled by file naming.
- CJK deliveries requiring ruby annotation or vertical text, which need IMSC 1.1 or later.
If the same programme also goes to broadcast, the second deliverable will be SCC or MCC in North America and EBU-STL in Europe. Producing both from one project avoids two sets of timing errors.
How do I open an IMSC file?
An IMSC file is XML and opens in any text editor. The first thing to check is the profile declaration in the root element, because it tells you which version and profile the file claims to satisfy.
If the body contains image elements rather than text, you have an image-profile file. The subtitles are PNGs, either referenced or embedded as base64, and no amount of XML reading will reveal the words.
For text-profile files, the same caution applies as with TTML: the subtitle elements reference regions and styles defined in the head, so the markup around a subtitle tells you more about its appearance than the subtitle itself does.
Converting IMSC to another format
Converting out of a text-profile IMSC is a normal timed-text conversion. Converting out of an image-profile IMSC is not a conversion at all — it is optical character recognition, with the accuracy that implies.
| Convert IMSC to | What survives | What to watch for |
|---|---|---|
| TTML / DFXP | Everything, usually | A profile change rather than a conversion. Confirm what the receiving validator expects. |
| WebVTT | Text, approximate positioning | Regions flatten into cue settings. Font, size and precise colour are dropped. |
| SRT | Text and line breaks | All styling and positioning discarded, and simultaneous regions flatten into one sequence. |
| SCC | Text, italics, approximate placement | Colours reduce to seven, regions snap to a character grid, and output must be 29.97 fps. |
| MCC | Text, styling, placement | More survives than in SCC, and the frame rate is a choice rather than a constraint. |
| EBU-STL | Text, colour, placement | Regions become teletext rows and a 25 fps timing base is required. |
| EBU-TT-D | Everything, usually | Both are TTML profiles. The differences are in required attributes rather than in what the subtitles can express. |
Converting another format to IMSC
Converting into IMSC usually means adding structure rather than losing it. The risk is producing a file that is valid TTML but fails the platform's specific profile validation.
| Convert to IMSC from | What carries over | What the conversion has to decide |
|---|---|---|
| TTML / DFXP | Everything | Which IMSC version and profile to target, and removing any feature outside it. |
| WebVTT | Text, positioning, basic styling | How cue settings become named regions, and what default styling to author. |
| SRT | Text and line breaks | A complete region and style model. The default region placement determines the whole look. |
| SCC | Text, italics, placement | Whether to preserve the 608 grid as regions or normalise to a single bottom-centre region. |
| MCC | Text, styling, placement | Which caption service to read, and how to express 708 windows as regions. |
| EBU-STL | Text, colour, placement | Teletext rows become percentage regions, and the palette becomes explicit colour values. |
Closed Caption Creator reads and writes every format in both tables. See the full file format support list, or the conversion API and CLI for batch workflows.
Where IMSC deliveries go wrong
IMSC rejections are usually about conformance rather than content. The subtitles are correct; the document does not satisfy the profile the platform asked for.
- Targeting the wrong version. IMSC 1.1 features in a file delivered against an IMSC 1.0 spec will fail validation even though the subtitles are perfect.
- Assuming the image profile is convertible. Image-profile subtitles are bitmaps. There is no text in the file to extract, so any text output requires OCR and manual correction.
- Losing the forced-display signal. Forced subtitles are signalled explicitly in IMSC. Converting to a format without that concept, then back, loses the distinction entirely.
- Region layouts that assume one aspect ratio. Regions are percentages of the frame. A layout designed for 16:9 lands differently on a 2.39:1 master unless the aspect ratio is accounted for.
For a worked platform delivery, see conforming captions for Netflix.
IMSC conversion questions
Common questions about moving subtitles into and out of the IMSC format.
Yes, for text-profile files, with the usual reductions. Arbitrary colours become the seven CEA-608 colours, percentage regions snap to a 32 by 15 character grid, and the output has to be 29.97 fps, which may mean conforming a file authored at 23.976 or 25. Forced-display signalling has no equivalent in SCC and is lost.
Not directly. The image profile carries subtitles as PNG bitmaps, so there are no characters in the file to extract. Producing SRT, WebVTT or SCC from one requires optical character recognition followed by human correction, and the timing is the only part that transfers reliably. Ask the supplier for a text-profile version before resorting to OCR.
Approximately. Both position subtitles as percentages of the frame, so the mapping is more natural than converting to a character-grid format. What does not survive is the finer styling: font family, font size, background opacity and IMSC-specific attributes such as line gap fill have no WebVTT equivalent.
IMSC 1.1 adds ruby annotation, text combination for CJK layouts, and high dynamic range signalling, alongside other TTML2 features. Converting 1.1 to 1.0 means removing anything in that set, which is lossless only if the file never used it. Converting 1.0 to 1.1 is straightforward, but check the platform accepts the newer version.
Almost always because the file is valid TTML but not valid against the specific profile requested. Platforms require particular attributes to be present, particular features to be absent, and a matching profile declaration in the root element. Validate against the named profile and version rather than against TTML generally.
Yes, and it is a light conversion because both are TTML profiles. The subtitle content and timing carry over intact; what changes is which attributes are required and which features are permitted. Treat it as a conformance exercise rather than a data conversion, and validate the output against the EBU-TT-D requirements.
Deliver IMSC that passes validation
Closed Caption Creator writes IMSC to the version and profile your platform specifies, with regions, styling and forced-display signalling intact.
Produce the matching SCC, MCC or EBU-STL broadcast deliverable from the same project, timed once.