Subtitle File Formats: Five Delivery Picks for Production Teams
Subtitle File Formats: Five Delivery Picks for Production Teams

Use SRT when you need a universal sidecar file that works almost anywhere. Use WebVTT when subtitles need to live natively inside a web video player. Choose TTML or IMSC when a broadcaster or streaming platform demands structured, professional delivery, and reach for ASS or SSA when a project needs heavy styling. Save everything in UTF-8 and check it in the actual target player before you ship.
TL;DR:
- SRT contains only an index, timecodes, and text, so it cannot natively position captions or apply complex visual styling within the file.
- WebVTT requires a WEBVTT header and periods before milliseconds, and it is the native format for HTML5 video tracks; SRT conversion needs both syntax changes.
- TTML or IMSC deliveries must be validated against the target profile, because a format conversion alone may fail distributor requirements and produce inconsistent rendering.
- VobSub and PGS store subtitles as images, preserving exact fonts and placement for DVD and high definition disc delivery when text rendering cannot be guaranteed.
- Save every subtitle file as UTF-8 without a byte order mark, then test it in the target player to catch encoding or rendering errors.
Table of Contents
- 1. SRT (SubRip): structure, compatibility, and limits
- 2. WebVTT (.vtt): web-native cues, styling blocks, and browser behavior
- 3. TTML / DFXP / IMSC: when broadcasters and streaming services require XML-based timed text
- 4. ASS / SSA: precise styling and animation for subtitle-heavy content
- 5. Image-based and container-embedded subtitle formats (VobSub, PGS, Matroska storage)
- 6. How to choose the right subtitle format: a practical checklist
- 7. Creating and exporting subtitles: steps and common pitfalls (encoding, validation)
- 8. Posthive workflow perspective: managing subtitle files across review and delivery
- 9. Quick recap and practical default picks
- 10. Keep your production workflow in one place
- A note on where teams usually compromise
- FAQ
- Sources
1. SRT (SubRip): structure, compatibility, and limits
SRT remains among the most widely supported subtitle formats. Each entry has a numeric index, a start and end timecode in HH:MM:SS,mmm format, and a line of text, nothing more. That simplicity is exactly why it works everywhere: SRT is a simple plain-text subtitle format built from a counter, timecodes, and text, with no dependency on a specific player or codec.
That same simplicity is also its ceiling. SRT does not natively support positioning text on screen, font changes, or complex styling beyond basic markup, which some players may interpret inconsistently.
- Index, timecode, and text only: no built-in styling or positioning tags
- Accepted almost universally by media players, editing software, and social platforms
- Encoding matters: a byte order mark or the wrong charset can turn accented or non-Latin characters into garbled text
SRT fits best for universal sidecar delivery: client review copies, archival masters, or any upload where the platform just needs plain, readable captions.
2. WebVTT (.vtt): web-native cues, styling blocks, and browser behavior
WebVTT is the subtitle format built for the web. It opens with a required WEBVTT header and uses a period instead of a comma to separate milliseconds in timecodes, a small but common source of conversion errors when moving from SRT. According to the WebVTT specification from the W3C, files must be UTF-8 encoded and support STYLE blocks for CSS-like formatting.
WebVTT is also the only subtitle format natively supported by the HTML5 <track> element, which makes it the default choice for any subtitle track embedded directly in a web video player rather than delivered as a standalone file for a third-party platform. The MDN WebVTT guide details cue structure, allowed inline tags, and how STYLE blocks interact with the ::cue selector for presentation control.
- Requires the
WEBVTTheader on the first line of the file - Supports STYLE blocks, positioning, and metadata beyond plain SRT
- Converting from SRT usually just means fixing the timecode separator and adding the header
Most conversion problems between SRT and WebVTT come from these small syntax mismatches rather than any real structural incompatibility.
3. TTML / DFXP / IMSC: when broadcasters and streaming services require XML-based timed text
TTML (Timed Text Markup Language) is an XML-based format built for professional delivery rather than casual uploads. The Library of Congress documentation on TTML describes it as a format used for authoring, interchange, and distribution, typically saved with a .ttml or .dfxp extension and carrying the MIME type application/ttml+xml.
Profiles like IMSC1 narrow TTML’s broader feature set into something distributors can rely on for consistent rendering across devices and platforms. That consistency is the whole point: a broadcaster or streaming service needs every subtitle to render the same way regardless of which player or device the viewer uses, and an XML structure with defined profiles makes that possible in a way plain text cannot.
- XML-based structure with defined profiles such as IMSC1 for strict interoperability
- Common extensions include
.ttmland.dfxp, with MIME typeapplication/ttml+xml - Conversion from SRT or WebVTT to TTML usually requires validation against the target profile, not just a format swap
If a distributor’s delivery spec names TTML or IMSC, treat it as a requirement rather than an option. Converting at the last minute without validating against the profile is a common way deliverables get rejected.
4. ASS / SSA: precise styling and animation for subtitle-heavy content
ASS and SSA subtitle files store far more than text and timing. They carry font definitions, color and positioning styles, karaoke timing tags, and effects that let a subtitle track move, fade, or highlight word by word. Anime fan-subbing communities popularized the format for exactly this reason: dense, stylized text that plain SRT or WebVTT simply cannot express.
Desktop players like VLC and MPC-HC handle ASS/SSA styling well, but web browsers have no native support, so these files are rarely the right pick for a web-embedded player.
- Stores styles, fonts, positioning, and karaoke-style timing tags
- Strong support in desktop media players, weak or absent support in browsers
- Common in workflows producing stylized credits, lyric videos, or heavily annotated fan content
Pick ASS/SSA when a project genuinely needs that level of visual control and the delivery target is a desktop player rather than a browser or broadcast pipeline.
5. Image-based and container-embedded subtitle formats (VobSub, PGS, Matroska storage)
Some deliverables call for subtitles as images rather than text. VobSub (used on DVDs) and PGS (used on Blu-ray) render each subtitle as a bitmap, preserving exact fonts and positioning regardless of what the playback device supports, which matters for optical media where text rendering can’t be guaranteed.
Containers like Matroska (MKV) can embed both text and image-based subtitle tracks directly into the video file. According to Matroska’s technical documentation, SRT is stored internally as S_TEXT/UTF8, WebVTT as S_TEXT/WEBVTT, and ASS/SSA headers live in the file’s CodecPrivate data, while image subtitles are stored as timestamped blocks.
- Image-based formats preserve exact visual fidelity for DVD and Blu-ray delivery
- Matroska can embed SRT, WebVTT, or ASS/SSA tracks using specific codec IDs, with text converted to UTF-8
- Embed subtitles in the container when you want a single self-contained file; keep them as sidecar files when a platform needs to process or translate them independently
6. How to choose the right subtitle format: a practical checklist
Match the format to the job before you touch an export setting.
- Identify the target platform: web player, broadcast, DVD/Blu-ray, or social upload
- Decide whether you need styling or positioning beyond plain text
- Check the distributor’s delivery spec for a named format requirement
- Consider whether the file needs to be archived or repurposed across multiple targets
- Confirm your editing toolchain actually exports the format you need cleanly
| Common job | Recommended format |
|---|---|
| Universal sidecar delivery | SRT |
| Embedded web video player | WebVTT |
| Broadcast or streaming distribution | TTML / IMSC |
| Heavily styled or karaoke content | ASS / SSA |
| DVD or Blu-ray authoring | Image-based (VobSub, PGS) |
7. Creating and exporting subtitles: steps and common pitfalls (encoding, validation)
Building a clean subtitle file is straightforward once you know the structure each format expects.
- For SRT, write a numeric index, a start and end timecode separated by a comma before milliseconds, then the subtitle text on the next line
- For WebVTT, start the file with the
WEBVTTheader, then list cues with a period before milliseconds - Save every file as UTF-8 without a byte order mark, since the wrong encoding is the most common cause of garbled accented or non-Latin characters
- Spot-check the exported file in the actual target player, not just a text editor
- Watch for frame-rate or timecode drift when repurposing a subtitle file across a different delivery target
Our guide to auto-caption workflows walks through managing sidecar exports at scale if you are producing captions regularly rather than as a one-off task.
Pro Tip: Keep a master UTF-8 sidecar file for every project so you can regenerate any other format on demand instead of re-exporting from scratch.
8. Posthive workflow perspective: managing subtitle files across review and delivery
Subtitle errors rarely come from picking the wrong format. They come from version confusion: a translator working from an outdated cut, or a timecode that drifted after a re-edit. Version control tied to timecoded review catches that before delivery, and our timecoded video comments feature ties feedback directly to the frame it refers to, which keeps markers from drifting between review rounds.
A two-pass QA process, one pass for translation accuracy and one for timecode and encoding, catches most delivery errors before they reach a client. Our subtitle translation workflow guide covers how centralized asset ownership keeps every subtitle version traceable to its source cut.
Pro Tip: Lock your picture edit before starting the final subtitle pass to avoid timecode drift across versions.
9. Quick recap and practical default picks
Use SRT for universal sidecar delivery, WebVTT for web-embedded players, TTML or IMSC for professional broadcast and streaming distribution, and ASS or SSA when a project needs heavy styling. Whichever you choose, save it in UTF-8 and validate it in the actual target environment before delivery.

10. Keep your production workflow in one place
Picking the right subtitle format solves half the problem. The other half is making sure the right version of that file reaches the right person without five email threads and a guessing game about which cut it matches. 
We built our platform around that gap: direct client ownership of deliverables, streamlined version control, and unlimited free seats on every plan so your whole team and your clients can review and approve without anyone paying per seat. Calendar integration and NLE plugins keep subtitle rounds tied to the same timeline your editors are already cutting on, so a translated SRT or a styled ASS file never gets separated from the cut it belongs to.
Compare the Pro and Enterprise plans to see which fits your team’s storage and review needs, or look through our productivity tools to see how version control and task tracking fit into a subtitle-heavy delivery schedule.
A note on where teams usually compromise
Most teams default to SRT because it is the path of least resistance, then discover mid-project that a platform or client actually needed WebVTT or TTML. The trade-off is rarely about which format is “better.” It is about matching the format to the specific delivery requirement before you build your workflow around the wrong one. For deeper technical reading, our video translation workflow checklist and the captioning workflow guide cover the practical side in more detail, and subtitle accessibility also affects discoverability, as covered in this video SEO guide.
— Lorenz
FAQ
How do you create a subtitle file?
You create a subtitle file by writing timed text entries in a plain text editor or export tool: an index, a start and end timecode, and the caption text, saved with the correct extension (.srt or .vtt). Most editing software can export this automatically, but always save the file in UTF-8 and check it in your target player.
What are different types of subtitles?
Subtitle types include plain-text formats like SRT and WebVTT, XML-based professional formats like TTML and IMSC, styled formats like ASS and SSA, and image-based formats like VobSub and PGS used on DVD and Blu-ray. Each serves a different delivery job, from universal web uploads to strict broadcast specs.
What is SRT vs VTT?
SRT and WebVTT share a similar structure but differ in syntax and capability. WebVTT requires a header and a period before milliseconds, while SRT uses a comma and no header, and WebVTT also supports native browser playback and STYLE blocks that plain SRT lacks.
Does an MP4 have subtitles?
An MP4 file can contain embedded subtitle tracks, but it does not automatically include them unless they were added during export or muxing. Many deliverables instead use a separate sidecar file, such as SRT or WebVTT, alongside the MP4 rather than embedding subtitles directly.
What subtitle format do platforms like YouTube accept?
YouTube’s caption support documentation recommends simple formats like SRT or SubViewer for basic uploads, while supporting more advanced formats for specialized workflows. Checking a platform’s specific caption guidelines before export avoids rejected or misformatted uploads.
Sources
- SubRip Subtitle format (SRT) — Library of Congress
- WebVTT: The Web Video Text Tracks Format — W3C
- YouTube help: Caption file formats — Google Support