Caption Format Reference
CAP File Format (.cap)
.cap is an extension, not a format. At least three unrelated caption formats use it, they are not interchangeable, and a tool that reads one will usually reject the others. Identifying which one you have is the whole job; the conversion afterwards is routine.
What is a .cap file?
A .cap file is a closed caption file from one of several unrelated legacy systems — most commonly Cheetah, NCI, or Videotron Lambda. They share an extension and nothing else. The file has to be identified by its contents before it can be opened or converted.
CAP at a glance
The table below covers the variants most likely to arrive in a North American captioning workflow. Cheetah also produced a plain-text form with its own extension, which is worth knowing about because it is often confused with the binary one.
| Property | Value |
|---|---|
| Extension | .cap, shared by unrelated formats |
| Cheetah (binary) | A binary caption file from Cheetah International captioning systems |
| Cheetah (ASCII) | The plain-text companion form, normally carrying an .asc extension |
| NCI Caption | A caption format associated with the National Captioning Institute |
| Videotron Lambda | A caption format from the Videotron Lambda captioning system |
| Caption standard | North American, 608-oriented in practice |
| Timing | Frame-based, tied to the originating system's rate |
| Positioning | Row and column placement, as with other 608-era formats |
| Current status | Legacy. Encountered as source material rather than as a deliverable |
| Closed Caption Creator | Reads Cheetah binary, Cheetah ASCII, NCI and Videotron Lambda |
All four variants appear separately on the full file format support list, which is the quickest way to confirm a given variant is supported.
What CAP can and cannot carry
Capabilities vary between the variants, but they were all built for the same delivery target — North American line 21 captioning — so the practical ceiling is what CEA-608 can express.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | Upper and lower case |
| Row and column positioning | Yes | On a 608-style character grid |
| Italics and underline | Yes | As 608-era text attributes |
| Text colour | Yes | The 608 palette of seven colours |
| Pop-on and roll-up styles | Yes | Declared per caption |
| Explicit end times | Partial | Varies by variant; some carry an out time, others clear on the next caption |
| Non-Latin scripts | No | These are 608-era North American formats |
| Embedded frame rate | Partial | Often implied by the originating system rather than stored |
| Two languages in one file | Partial | Where the variant supports 608 channels |
| Fonts and text size | No | Appearance is decided by the decoder |
Where do .cap files come from?
Nobody specifies CAP as a deliverable in 2026. It arrives as legacy material, and the task is nearly always to get it into a current format.
- Archive and library digitisation, where the caption asset predates SCC becoming universal.
- Facilities migrating off Cheetah, NCI or Lambda captioning systems.
- Rights holders repurposing older catalogue titles for streaming.
- Clients sending whatever caption file they have on record, without knowing what it is.
The usual destination is SCC or MCC for broadcast, or SRT and WebVTT for online use.
How do I know which .cap format I have?
Start by opening it in a text editor. If the contents are readable — timecodes and caption text you can follow — you have a plain-text variant such as Cheetah ASCII, regardless of what the extension says.
If the contents are mostly unreadable bytes, you have a binary variant, and the next step is to try opening it as each candidate in a tool that supports all of them. The correct variant produces sensible text and timecodes; an incorrect one produces either an error or obvious nonsense.
Ask the supplier where the file came from if you can. Knowing that a facility ran Cheetah, or that the file came from a Lambda system, saves the guesswork entirely. Do not rename the extension to force a tool to accept it — that changes nothing about the contents and hides the real problem.
Converting CAP to another format
Once the variant is identified, converting out is unremarkable. These are 608-era formats, so everything they carry has a home in SCC or MCC, and the usual reductions apply for text-based targets.
| Convert CAP to | What survives | What to watch for |
|---|---|---|
| SCC | Text, colour, placement | The natural target. Confirm the frame rate first, since it is often implied rather than stored. |
| MCC | Text, colour, placement | Preferable when the master is not 29.97 fps, because MCC declares its own rate. |
| SRT | Text and line breaks | Colour and placement are discarded. End times may need deriving depending on the variant. |
| WebVTT | Text, italics, approximate placement | Grid positions become percentages and colours become CSS classes. |
| TTML / IMSC | Text, styling, placement | The most complete target. Grid rows map onto regions. |
| EBU-STL | Text, colour, placement | Only relevant for a European re-delivery, and requires a frame rate conform. |
Converting another format to CAP
Converting into CAP is rare and usually unnecessary. It comes up when a facility still runs the originating system and needs material returned in its native format.
| Convert to CAP from | What carries over | What the conversion has to decide |
|---|---|---|
| SCC | Text, colour, placement | Which variant to target, and whether that variant expects explicit out times. |
| MCC | The 608 layer | Which caption service to read, and a frame rate the target system expects. |
| SRT | Text | Placement, line wrapping and a frame rate. SRT supplies none of them. |
| TTML / IMSC | Text, placement | Rich styling collapses to what a 608-era format can express. |
Closed Caption Creator reads all four .cap variants. See the full file format support list, or the conversion API and CLI for batch migrations.
Where .cap files go wrong
Every common CAP problem traces back to the same root cause: assuming the extension identifies the format.
- Renaming to force a tool to open it. Changing
.capto.sccchanges the filename and nothing else. The contents are still in the original format. - Assuming a frame rate. Several variants imply their rate from the originating system rather than storing it. Getting it wrong produces captions that drift progressively.
- Confusing the binary and ASCII Cheetah forms. They are different files with different structures. If a text editor shows readable content, it is the ASCII form.
- Batch-converting a mixed archive. A folder of
.capfiles may contain more than one variant. Identify before converting, or the failures will be silent.
For migrating a mixed legacy archive, the conversion API and CLI can identify and convert in a single pass.
CAP file questions
Common questions about identifying and converting caption files that use the .cap extension.
Open it in a text editor first. Readable timecodes and caption text mean a plain-text variant such as Cheetah ASCII. Unreadable bytes mean a binary variant, and the only reliable next step is to try opening it as each candidate in a tool that supports all of them. Asking the supplier which system produced it is faster than guessing.
They come from the same system and carry similar caption data, but they are different files. The CAP form is binary and the ASC form is plain text, which is why one opens readably in a text editor and the other does not. Tools list them separately because reading one does not imply reading the other.
Yes, once the variant is identified. The text and timing convert cleanly. What is discarded is placement and colour, which these 608-era formats do carry, so if the captions used positioning to avoid on-screen text that information is lost. Convert to WebVTT or TTML instead when placement matters.
Yes, and it is the most natural target, because both formats express the same underlying CEA-608 caption model. Colour, placement and caption style all have a direct equivalent. The one thing to confirm before exporting is the frame rate, since SCC exists only at 29.97 fps and the source rate is often implied rather than recorded.
Most likely because the tool supports a different .cap variant from the one you have. Support for Cheetah does not imply support for NCI or Videotron Lambda. Check which specific variants your tool lists rather than checking whether it supports “CAP files”, because that phrase does not identify anything.
Rarely. They turn up as archive material and as output from facilities still running the originating systems. For anything new, SCC or MCC is the North American deliverable. The practical reason to care about CAP is that catalogue titles being prepared for streaming often have a .cap file as their only existing caption asset.
Identify it, then move it forward
Closed Caption Creator reads Cheetah binary and ASCII, NCI and Videotron Lambda caption files, and exports to SCC, MCC, IMSC, WebVTT and SRT.
Migrate a mixed legacy archive in one pass rather than file by file.