CEA-608 and CEA-708: What Actually Differs, and Where Each Applies

Ask three people what "608 captions" or "708 captions" mean and you will often get three different, equally confident, mostly wrong answers. Part of the confusion is that both names get used loosely to mean "closed captions" in general, including on platforms where neither standard is actually in play. The other part is that people assume 708 is simply a newer version of 608 — same rules, more channels. It is not.

Getting the distinction right matters less for trivia and more for a practical reason: it tells you which rules apply to what you are actually delivering. A cable broadcast, a streamed webinar, and an uploaded recording are governed by different standards with different bodies behind them, and mixing them up leads to citing the wrong accuracy figure or the wrong format requirement to a client.

Two standards, two eras

CEA-608 — "Line 21" captioning — is the standard for closed captions embedded in line 21 of the vertical blanking interval of an analog NTSC video signal. It is the format behind captions on older broadcast television: a fixed grid of up to four lines of up to 32 characters, with four caption channels (CC1–CC4) and four text services, though in practice only CC1 and CC3 saw regular use. Its character set is a limited Latin/ASCII-derived set, later extended to cover French, Spanish, and German — it cannot represent non-Latin scripts.

CEA-708, also called DTVCC, is the standard built for closed captioning on ATSC digital television — the format that came with the shift to HD broadcasting. It supports a substantially larger character repertoire, absolute and percentage-based positioning instead of a fixed grid, and real styling: multiple font styles and sizes, dozens of text and background colours, adjustable background opacity, and edge effects like drop shadows. None of that exists in 608.

Both organisations behind these standards go by the same acronym today for a different reason: the Consumer Electronics Association renamed itself the Consumer Technology Association in November 2015, and CEA-prefixed standards were redesignated under the CTA prefix. So "CEA-608" and "CTA-608" are the same standard; you will see both names depending on how old the source is.

Both are at revision "E" — but that is where the parallel ends

It is true that the current version of each standard carries the letter E: ANSI/CTA-608-E ("Line 21 Data Services") and ANSI/CTA-708-E ("Digital Television (DTV) Closed Captioning"). It is tempting to read that as evidence the two standards get updated together. They do not. CTA-608-E stabilized in December 2019. CTA-708-E stabilized in 2023, with an errata sheet added the same year. Four years apart, on independent maintenance tracks — the shared letter is a coincidence of each standard's own revision count, not a joint release.

708 did not replace 608 — it carries it

The most common misconception about the pair is that 708 replaced 608 the way a new codec replaces an old one, leaving 608 obsolete. That is not how the digital transition actually works.

A CTA-708/DTVCC transport stream carries backward-compatible, encapsulated line-21-equivalent data — informally, "608 compatibility bytes" — alongside native 708 data in the same stream. A legacy 608-only decoder can still pull usable captions out of a digital broadcast because that older-format data is still there, riding along inside the newer container. The digital transition service architecture also supports a much larger number of addressable caption services (up to 63, by service number) than 608's four channels, though that is a ceiling for the architecture, not something a typical broadcast uses — most broadcasts carry one or two active language services regardless of how many the format can address.

So the accurate framing is: 708 is layered on top of 608, not swapped in for it. If you are troubleshooting why a digital broadcast's captions look identical to what an old CRT-era decoder would have shown, this is why — you may be looking at the compatibility layer, not the native 708 rendering.

The CRTC accuracy standard is three numbers, not one

This is the part that gets misreported more than anything else in Canadian broadcast captioning, and it is worth being precise about because the wrong version circulates constantly in compliance and marketing writing alike.

There is no single "CRTC requires X% caption accuracy" rule. There are three separate regimes, from two separate policies:

• English-language live programming must reach an accuracy score of at least 98, measured using the NER model described in the Canadian NER Evaluation Guidelines, under CRTC 2019-308. This is a point-deduction score starting from 100, not a percentage of words correct. Rendering it as "98% accuracy" — which happens constantly — misstates what is actually being measured.
• French-language live programming is governed by a separate, earlier policy, CRTC 2011-741-1, left standing by the 2019 English-language policy rather than replaced by it. It sets an accuracy threshold of at least 85%, calculated by an explicit formula: accuracy = (N − Sup − Sub − I) / N × 100, where N is the number of words in the audio, and Sup, Sub, and I are the words suppressed, substituted, and inserted by the captioner.
• Pre-recorded programming, both languages, is held to a target of 100% accuracy, including spelling, under the same 2019 policy.

Three regimes, two measurement systems, and only one of the three is expressed the way people usually assume all of them are. French live captioning genuinely is a percentage. English live captioning is not — it is a score on a different scale that happens to land near the same number, which is almost certainly why the two get conflated. Treat any single "the CRTC requires 98% accuracy" claim you encounter as a simplification that has already lost the detail that makes it useful.

One more boundary worth stating plainly: these are broadcast-television standards. They say nothing about the accuracy of CART captioning in a courtroom, a classroom, or a business meeting, or about caption quality on a streamed webinar — different context, different (or no) governing standard.

Broadcast captions are not web captions

This is the second place things routinely go wrong, and it matters directly if you are choosing a caption format for something you are streaming rather than broadcasting.

CEA-608 and CEA-708 are formats embedded directly in a broadcast video signal. Web and OTT streaming use a different family of formats entirely — WebVTT, SRT, and IMSC — delivered as separate sidecar files or inline with a stream rather than encoded into the signal itself. These are not interchangeable layers; converting between broadcast-embedded caption data and a web caption file (extracting 608/708 byte data and re-encoding it as WebVTT, for instance) is an active, deliberate step, not something that happens automatically.

The three web formats are not equivalent to each other in governance, either, which is worth knowing before you describe any of them as "the standard":

• WebVTT, the de facto format for web and HLS/DASH streaming, remains a W3C Candidate Recommendation Draft — it has not reached full W3C Recommendation status, despite functioning as the practical default across the industry.
• IMSC1, a TTML-based profile for internet subtitles and captions, did reach full W3C Recommendation status, in April 2016, with further revisions following as Recommendations of their own.
• SRT has no governing standards body at all — no W3C, CTA, or ATSC specification behind it. It originated as a ripping tool's native output and became a de facto interchange format purely by widespread convention, not by any formal process.

There is one genuine, narrow exception to the broadcast/web split: Apple's HLS specification supports embedding CEA-608 caption data directly inside the video elementary stream, per ATSC A/72, as an alternative to a sidecar WebVTT file. It is a real case of a broadcast-native format travelling inside a web-delivered stream without conversion — but it is an exception worth naming precisely because it is not how streaming caption delivery works by default.

Which one applies to what you are actually doing

If you are producing or distributing content that goes out over-the-air, cable, or satellite as broadcast television, 608/708 is the embedded format your signal chain needs to carry correctly, and the CRTC's accuracy regimes above are the ones that govern it. That is a broadcast and AV production question about signal chain and captioning workflow, not a streaming-platform question.

If you are delivering a livestream or event webcast, a recorded webinar, or on-demand video through a web platform, you are working in WebVTT/SRT/IMSC territory, not 608/708 — and none of the CRTC broadcast accuracy figures above apply to that content by default, however often they get cited as if they did. Live-event captioning and post-production transcripts for that kind of content fall under our transcription and captioning service rather than a broadcast-signal standard. For a related question about what Ontario law actually requires for captioning that kind of content, see our piece on AODA captioning requirements.

Either way, the standard that applies is determined by the delivery mechanism, not by what feels like "the more official" name. If you are not sure which category your event falls into, talk to us before the event rather than after.