Guide
Subtitle file formats
There are dozens of subtitle formats and about five that matter. The differences come down to one question: how much beyond the words and the timings does the format carry, and what does that cost in support?
The formats worth knowing
| SRT | Plain text: numbered blocks, timings, and words. Carries essentially no styling, which is exactly why almost everything accepts it. The safe default. |
|---|---|
| WebVTT | The web standard, designed for HTML5 video. Structurally close to SRT, with a header line, a period instead of a comma before milliseconds, and optional positioning and styling. |
| ASS and SSA | Advanced SubStation Alpha. Full control over font, colour, position, and animation. Widely used in fansubbing and anywhere typesetting matters, and correspondingly less portable. |
| TTML and DFXP | An XML standard used in broadcast and streaming delivery. Precise and verbose, and rarely something you hand-edit. |
| SCC | Broadcast closed captions, encoding the byte pairs of the older CEA-608 caption system. Required in some delivery specifications and awkward everywhere else. |
Choosing between them
- Uploading somewhere you do not control: SRT. Broadest support by a wide margin.
- Embedding in your own web player: WebVTT. It is what HTML5 video expects, and it can carry positioning.
- Styling and placement genuinely matter: ASS, accepting that fewer things will read it.
- Delivering to a broadcaster or a streaming platform with a spec: whatever the spec says, which is usually TTML or SCC.
- Social feeds: none of the above. Most of them do not read subtitle files, which is what burning in solves.
Converting between them
Converting downward, from a rich format to a plain one, is straightforward and lossy: the styling is dropped and the words and timings survive. Converting upward adds nothing, since the information was never there. The practical consequence is that your master copy should be the format that carries the most information you actually care about, and everything else should be generated from it.
The things that break in every format
- Encoding. Save as UTF-8. Formats that predate universal Unicode do not record their own encoding, so anything else is a guess that eventually goes wrong.
- Frame rate. Formats that count in frames rather than clock time desynchronise when the video is converted between frame rates.
- Line endings. Some parsers are strict about the difference between Windows and Unix line endings, and a file that loads in one player fails silently in another.
- Overlapping timings. Undefined in most formats, and every player handles it differently.
What you get here
Downloads are SRT and TXT, plus the MP4 with the subtitles burned in. SRT because it loads almost everywhere, TXT because a plain transcript is what you want for show notes, articles, and search, and burned in because that is what social feeds need. See what is an SRT file for the format in detail.
Generate subtitle files from your own video with 50 free credits.
Continue with Google50 free credits. No credit card needed.Frequently asked questions
Which subtitle format has the best support?
SRT, by a wide margin. It carries almost nothing beyond words and timings, which is precisely why nearly every player and platform accepts it.
What is the difference between SRT and WebVTT?
WebVTT is the web standard version of the same structure. It adds a header line, uses a period rather than a comma before milliseconds, and supports positioning and styling that SRT has no equivalent for.
When should I use ASS instead of SRT?
When font, colour, and exact placement are part of the point and you control the player. ASS carries full typesetting; the cost is that far fewer things will read it.
Can I convert an SRT to another format?
Yes. Converting from SRT to a richer format is easy but adds no information, since the styling was never in the file. Converting the other way drops the styling and keeps the words and timings.