IMSC as a Universal Subtitle Interchange Format

Every post-production facility eventually faces the same problem: a subtitle file arrives in one format, needs to be delivered in three others, and somewhere in the chain, styling disappears, positioning breaks, or timing drifts. The root cause is almost always the same — the team stored their canonical version in a format that was never designed to carry the full signal.

SRT is not an archive format. VTT is not an archive format. They are delivery endpoints. The format that should sit at the center of your subtitle pipeline is IMSC.

What IMSC Actually Is

IMSC (Internet Media Subtitles and Captions) is a constrained profile of TTML (Timed Text Markup Language), standardized by the W3C. It defines two profiles:

• IMSC1 Text Profile — styled, positioned timed text in XML
• IMSC1 Image Profile — bitmap-based subtitles for scenarios requiring pixel-perfect rendering

IMSC is not a theoretical spec that nobody uses. Netflix mandates IMSC for all subtitle deliveries. Disney+, Apple TV+, and most major streaming platforms either require or accept it. The broadcast-to-streaming transition has made IMSC the de facto interchange standard.

The Lossy Transport Problem

Consider what each common format actually preserves:

When you store your master subtitles in SRT, you have already thrown away positioning, styling, region layout, language metadata, and accessibility attributes. That information is gone. If a downstream delivery later requires any of it, someone has to recreate it manually.

This is the same principle as audio: you do not master to MP3 and then try to derive FLAC from it. You master to a lossless format and down-convert to lossy endpoints as needed.

The Conversion Asymmetry

Format conversion is not symmetric. Converting up adds nothing; converting down loses data.

SRT to IMSC: You get valid IMSC, but with no positioning, no styling, no regions. The text and timing survive. Everything else is default.

IMSC to SRT: Positioning is stripped. Styling is stripped. Region definitions are stripped. Language metadata is stripped. You get bare text with millisecond timestamps.

This asymmetry means that the direction you convert matters enormously. If your archive format is SRT and you need to deliver IMSC, you are starting from a deficit every time. If your archive format is IMSC and you need to deliver SRT, you lose nothing that SRT was ever going to carry anyway.

The Practical Workflow

A frame-accurate subtitle pipeline looks like this:

1. Ingest — Accept any input format (SRT, VTT, SBV, ASS, SCC, EBU-STL). Parse it with framerate context. Convert timestamps to frame numbers immediately.
2. Normalize — Convert the parsed data to IMSC. Add any metadata the source format carried (styling from ASS, positioning from VTT, etc.). This is your canonical version.
3. Archive — Store the IMSC file. This is your master. All subsequent operations derive from it.
4. Export — When delivery requirements arrive, convert from IMSC to whatever the target platform needs. SRT for YouTube. VTT for HLS manifests. SCC for North American broadcast. EBU-STL for European broadcast.

The key insight: you never edit the downstream exports. You edit the IMSC master, then regenerate exports. This eliminates the version control nightmare of maintaining parallel SRT, VTT, and SCC files that inevitably diverge.

Why Not ASS?

ASS (Advanced SubStation Alpha) carries rich styling data — arguably more creative control than IMSC for certain use cases like karaoke and animation effects. So why not use ASS as the canonical format?

Three reasons:

1. ASS is not a standard. It is a format defined by a single application (Aegisub/VSFilter). There is no governing body, no formal specification, no compliance testing. IMSC is a W3C Recommendation with a defined conformance model.
2. ASS has no accessibility model. IMSC supports role attributes, forced display flags, and language tagging that are required for accessibility compliance in broadcast and streaming.
3. Industry adoption. No major streaming platform accepts ASS for delivery. Every major platform accepts or mandates TTML/IMSC.

ASS is excellent for creative subtitle work. But when that work is done, the result should be exported to IMSC for archival and downstream delivery.

Timing Precision

IMSC supports multiple timing models, including SMPTE timecodes and frame-based timing. This means an IMSC file can carry the same frame-accurate timing that broadcast formats like SCC and EBU-STL require — without the millisecond rounding that SRT and VTT force.

At timecode.dev, all subtitle operations run through the timecodes engine, which treats frame numbers as the canonical time representation. When you convert between formats, every timestamp goes through integer frame space first. This means converting SRT to IMSC to SCC does not accumulate rounding errors — each conversion step resolves to exact frame boundaries.

Getting Started

The subtitle tool supports IMSC as both an input and output format. You can:

• Upload any supported format and export to IMSC
• Upload IMSC and export to any target format (SRT, VTT, SBV, ASS, SCC, EBU-STL, and more)
• Use the subtitle converter for direct format-to-format conversion with IMSC as an intermediate

If you are building a subtitle pipeline for a facility that handles multiple delivery targets, stop storing SRT as your master. Up-res to IMSC, archive it, and down-convert to whatever each delivery window requires. You will save hours of rework and eliminate an entire category of QC failures.

The industry is already moving this direction. The only question is whether you adopt it proactively or reactively.