Subtitle and Caption Engineering: Specs, Speeds, Accessibility

Delivering video content across languages and platforms demands far more than translating dialogue. Subtitle and caption files must conform to precise timing constraints, reading-speed limits, format specifications, and accessibility standards, all while remaining invisible enough that viewers stay immersed in the content. A single frame-rate mismatch or a poorly segmented line can derail comprehension, trigger compliance failures, or force costly rework. This guide covers the full engineering stack: file formats and their tradeoffs, timing and typographic rules, accessibility requirements, and the validation workflow that ensures clean delivery to YouTube, OTT platforms, and social channels. Whether you manage a library of thousands of hours or a single high-stakes launch, these specifications form the foundation of scalable subtitle quality.

If your team is navigating these complexities at scale, explore how Ollang streamlines subtitle and caption engineering across formats, languages, and platforms.

Subtitle and Caption Formats Compared

SRT: Simplicity and Limitations

SubRip (SRT) remains the most widely supported subtitle format. Its plain-text structure, sequential index, timecode pair, and text block, makes it easy to author and parse. However, SRT supports no native styling, positioning metadata, or speaker identification. Any formatting (bold, italic) relies on informal HTML-like tags that renderers may ignore. SRT uses comma-separated millisecond timecodes (HH:MM:SS,mmm), which creates conversion friction when moving to frame-based workflows. Use SRT when the delivery platform explicitly requires it or when no advanced styling is needed.

WebVTT: Web-Native Flexibility

Web Video Text Tracks (WebVTT) extends SRT's simplicity with CSS-like cue styling, vertical text support, and positioning via line/position/align properties. It uses period-separated millisecond timecodes (HH:MM:SS.mmm). WebVTT is the native caption format for HTML5 <video> and is required by most web players. Its NOTE blocks allow metadata comments, and its ::cue pseudo-element enables platform-consistent typography. Choose WebVTT for web delivery, progressive web apps, and any context where you need positioning control without a full broadcast spec.

TTML/IMSC: Broadcast and Streaming Compliance

Timed Text Markup Language (TTML) and its constrained profile IMSC (Internet Media Subtitles and Captions) are XML-based formats used by major streaming platforms and broadcast networks. IMSC is the W3C recommendation for internet subtitle interchange. These formats support:

• Region-based positioning with pixel or percentage coordinates
• Full typographic control (font family, size, color, background, outline)
• Ruby annotations for East Asian languages
• Embedded or referenced images for bitmap subtitles

TTML/IMSC is required for Netflix, Disney+, and many European broadcasters. The complexity of the XML schema means authoring typically requires dedicated tools, but the precision is unmatched for multi-platform delivery.

EBU-STL: Legacy Broadcast Standard

EBU-STL (European Broadcasting Union Subtitle Transfer Language) is a binary format defined in EBU Tech 3264. It encodes timecodes as frame-based values, supports teletext and open subtitle modes, and carries metadata about language, display standard, and character set. While largely a legacy format, EBU-STL remains mandatory for many European terrestrial and cable deliveries. Its binary nature makes it opaque to text editors, requiring specialized conversion tools.

Timing Rules and Reading-Speed Standards

Characters per Second by Content Type and Market

Reading speed is the single most critical parameter governing subtitle quality. It determines whether viewers can comfortably absorb text while following visual action. The industry standard for adult entertainment content sits between 15 and 17 characters per second (CPS), with some platforms specifying a maximum of 17 CPS for many languages. Children's content typically requires 13 CPS or lower to accommodate developing reading skills.

Market-specific norms vary. Scandinavian markets, where subtitle literacy is high, tolerate speeds near the upper bound. Markets with complex scripts, Arabic, Thai, Japanese, require adjusted calculations that account for character density and reading direction. For educational or accessibility-focused content, many guidelines recommend staying at or below 15 CPS regardless of market.

Minimum and Maximum Duration Constraints

Beyond reading speed, individual subtitle events need duration guardrails:

• Minimum duration: 0.7-1.0 seconds. Anything shorter creates a flash that viewers cannot register.
• Maximum duration: 7 seconds for a two-line subtitle. Longer durations cause viewers to re-read text, breaking immersion.
• Gap between subtitles: A minimum of 2 frames (approximately 80 ms at 25 fps) ensures the eye registers a subtitle change. Some platforms require a full 120 ms gap.

These constraints interact: a short utterance still needs minimum screen time, while a dense line must be split rather than displayed at excessive speed.

Line-Breaking and Segmentation Heuristics

How text is divided across lines and subtitle events directly affects comprehension. Core segmentation principles:

• Break at clause or phrase boundaries, never mid-phrase
• Keep articles, prepositions, and conjunctions with the noun or clause they introduce
• Prefer a longer top line and shorter bottom line (inverted pyramid) for visual stability
• Never separate a modifier from its head noun across lines
• Limit to two lines per subtitle event; three lines only where platform and content type explicitly allow it

Example of an unnatural break:

I told her that we should
leave before the storm.

Corrected to keep the verb phrase intact:

I told her
that we should leave before the storm.

Positioning, Typography, and Platform Constraints

Safe Areas and UI Avoidance

Subtitles must avoid overlapping with player controls, channel bugs, lower thirds, and platform UI elements. The traditional broadcast safe area (roughly 90% of frame width, 80% of height) provides a starting point, but modern platforms impose tighter constraints:

• YouTube's progress bar and controls occupy roughly the bottom 10-12% of the player during interaction
• Mobile players with gesture zones require additional vertical margin
• Social platforms with persistent UI (likes, comments, share buttons) demand positioning in the center or upper third of the frame

When subtitles must move to avoid on-screen text or graphics, use TTML regions or WebVTT position/line properties to shift cues vertically. Burned-in subtitles require re-rendering if positioning changes after delivery.

Typography Across Renderers

Font rendering varies dramatically across platforms. A subtitle that looks clean in a desktop browser may become illegible on a smart TV at viewing distance. Key typographic decisions:

• Font choice: Sans-serif faces (Arial, Roboto, Noto Sans) ensure legibility across devices. Noto Sans covers virtually all Unicode scripts.
• Size: Typically 5-8% of video height for readability at standard viewing distances.
• Outline and shadow: A 1-2 pixel dark outline or drop shadow ensures contrast against variable backgrounds. Avoid relying solely on semi-transparent boxes, which can obscure image content.
• Background box: Some platforms mandate a semi-transparent background for accessibility. Others allow outline-only styling.

IMSC profiles define these parameters precisely, ensuring consistent rendering across compliant players.

Sidecar vs. Open Captions vs. Forced Narratives

Sidecar subtitles are delivered as separate files alongside the video asset. They can be toggled on or off by the viewer, updated without re-encoding video, and swapped between languages. This is the standard approach for OTT and web delivery.

Open (burned-in) captions are rendered directly into the video frame during encoding. They cannot be turned off. Use open captions only when:

• The platform does not support sidecar tracks (some social feeds)
• Regulatory requirements mandate always-visible captions
• Creative intent requires specific typographic treatment that no player can replicate

Forced narrative subtitles are a distinct track that displays only when foreign-language dialogue or on-screen text appears within an otherwise same-language program. They are flagged as "forced" in container metadata (e.g., the forced flag in MKV or MP4 subtitle tracks) so players display them automatically without the viewer enabling full subtitles. Forced narratives require careful authoring to include only genuinely untranslated elements.

Frame Rate, Timecode Offsets, and Conversion Pitfalls

Retiming Between 23.976 and 25 fps

A common conversion scenario: content mastered at 23.976 fps for theatrical or US broadcast delivery must be retimed to 25 fps for PAL territories, or vice versa. The ~4% speed difference means every timecode in the subtitle file must be recalculated.

When converting 23.976 → 25 fps (PAL speed-up):

• Multiply all timecodes by 23.976/25 (≈ 0.95904)
• A subtitle at 00:10:00,000 in the 23.976 version lands at approximately 00:09:35,424 in the 25 fps version
• Duration of each event also compresses by ~4%

When converting 25 → 23.976 fps (PAL slow-down):

• Multiply timecodes by 25/23.976 (≈ 1.04271)
• Events stretch slightly

The critical pitfall: applying the wrong direction of conversion, or applying it twice, produces cumulative drift that becomes visible within minutes. Always verify the source frame rate from the video container metadata, not from filename conventions or assumptions.

Drop-Frame vs. Non-Drop-Frame Timecode

For 29.97 fps content (NTSC), drop-frame timecode skips frame numbers 0 and 1 at the start of each minute (except every tenth minute) to keep timecode aligned with wall-clock time. Non-drop-frame timecode counts every frame sequentially, drifting from real time by approximately 3.6 seconds per hour.

Subtitle files authored against drop-frame timecode will desynchronize if played against a non-drop-frame master, and vice versa. The format itself (SRT, WebVTT) uses clock time, not frame counts, so the conversion must happen at the point of timecode extraction from the video, not within the subtitle file.

SDH Compliance and Accessibility

What SDH Requires Beyond Standard Subtitles

Subtitles for the Deaf and Hard of Hearing (SDH) must convey all aurally significant information, not just dialogue. This includes:

• Speaker identification: Labels when the speaker is off-screen or when multiple speakers are present, typically in parentheses or brackets before the dialogue line.
• Sound effects: Described in brackets when they carry narrative significance. [door slams], [phone ringing], [tense music].
• Music description: Lyrics displayed with musical note symbols (♪) or described generically when lyrics are not relevant.
• Manner of speech: Whispered, shouted, or filtered dialogue indicated parenthetically.

SDH tracks are distinct from standard translation subtitles and must be authored separately, even for the same language.

Legal and Regulatory Landscape

Accessibility legislation in many jurisdictions mandates captioning for video content distributed to the public. In the United States, the FCC's captioning rules cover television and much online video that previously aired on TV. The Americans with Disabilities Act has been interpreted by courts to apply to certain online video services. The European Accessibility Act, taking effect in 2025, imposes captioning obligations on audiovisual media services across EU member states.

Rather than detailing specific penalty structures, which vary by jurisdiction and evolve through case law, teams should:

• Consult qualified legal counsel for obligations specific to their distribution territories
• Default to providing SDH captions for all public-facing content as a baseline
• Document captioning coverage and accuracy metrics for compliance reporting

If your organization needs to scale SDH-compliant captioning across multiple languages and platforms, see how Ollang handles accessibility-grade subtitle production.

Practical Engineering Examples

Fixing Orphan Words

An orphan word, a single short word left alone on the second line, creates visual imbalance and wastes screen space:

The investigation revealed
nothing.

Fix by redistributing text:

The investigation
revealed nothing.

Or, if reading speed allows, combine into a single line:

The investigation revealed nothing.

Automated QC tools can flag orphans (often defined as final-line words under 3-4 characters), but correction requires human judgment about segmentation quality.

Moving Subtitles to Avoid UI Overlap

Consider a cooking tutorial where ingredient lists appear as lower-third graphics. Default bottom-center subtitles would overlap. In WebVTT:

00:02:15.000 --> 00:02:18.500 line:10%
Season generously with salt and pepper.

The line:10% property positions the cue near the top of the frame. In TTML/IMSC, you define a named region with appropriate origin and extent coordinates, then assign cues to that region for the duration of the graphic overlay.

For burned-in subtitles, this repositioning must be planned during the subtitle authoring phase and baked into the render. Post-render repositioning requires full re-encoding.

Retiming Example: 23.976 to 25 fps

Original SRT timecode at 23.976 fps:

1
00:05:00,000 --> 00:05:03,500
We need to move quickly.

After PAL speed-up conversion (×0.95904):

1
00:04:47,712 --> 00:04:51,069
We need to move quickly.

The subtitle now appears approximately 12 seconds earlier in absolute time, matching the compressed audio/video timeline. Duration shrinks from 3.5 seconds to approximately 3.36 seconds, still within acceptable minimum duration.

Tooling, Validation, and Delivery Checklist

A production-grade subtitle engineering workflow typically includes authoring, conversion, validation, and platform integration. Ollang connects these stages via API to reduce manual handoffs and ensure consistent specs across delivery targets.

Recommended Tooling Stack

• Authoring: Ollang, Subtitle Edit, EZTitles, or OOONA for manual and semi-automated creation
• Conversion: Ollang, Subtitle Edit, ttconv, or proprietary pipeline scripts for format transformation
• QC/Validation: Ollang, Cavena, OOONA QC, or custom validators checking CPS, duration, overlap, formatting compliance
• Integration: Ollang-powered API pipelines connecting transcription, translation, timing, and delivery systems

Validation Steps Before Delivery

Before any subtitle file leaves production:

1. Format compliance: Validate XML schema (TTML/IMSC) or structural syntax (WebVTT, SRT)
2. Timing integrity: No overlapping events, minimum gaps respected, no negative durations
3. Reading speed: All events within target CPS for the content type and market
4. Line length: No line exceeds the platform's character limit (typically 37-42 characters for two-line display)
5. Segmentation: No mid-phrase breaks, no orphan words, no three-line events unless permitted
6. Positioning: Cues do not overlap safe-area boundaries or known UI elements
7. Character encoding: UTF-8 with BOM where required (some legacy systems expect it)
8. Spell-check and terminology: Language-specific validation against glossaries

To review your subtitle quality controls and acceptance criteria with our team, Schedule a subtitle QC review.

Platform Delivery Requirements

Handoff Checklist

• [ ] Correct format for each delivery platform
• [ ] Frame rate verified against video master
• [ ] Language and territory metadata populated
• [ ] SDH track authored separately where required
• [ ] Forced narrative track flagged correctly in container
• [ ] File naming follows platform convention (language code, type indicator)
• [ ] Final QC pass completed with zero critical errors
• [ ] Backup of source timing file retained for future retiming

Frequently Asked Questions

What is the difference between subtitles and SDH captions?

Standard subtitles translate or transcribe dialogue for viewers who can hear the audio but need text support, typically for foreign-language content. SDH captions additionally describe non-dialogue audio: sound effects, music, speaker identification, and manner of speech. SDH serves viewers who are deaf or hard of hearing and must convey the full auditory experience through text.

Which subtitle format should I use for multi-platform delivery?

TTML/IMSC provides the broadest professional coverage for OTT platforms and broadcast. For web-only delivery, WebVTT offers excellent styling and positioning with simpler authoring. SRT works as a universal fallback but lacks styling and positioning. Most scalable workflows author in TTML/IMSC and down-convert to SRT or WebVTT as needed per platform.

How do I prevent subtitle drift when converting between frame rates?

Always verify the source video's actual frame rate from container metadata before applying any conversion factor. Use the precise ratio (e.g., 23.976/25 for PAL speed-up) rather than rounding. After conversion, spot-check sync at the beginning, middle, and end of the file. Never apply a frame-rate conversion to a file that has already been converted, track conversion history in your asset metadata.

What reading speed should I target for translated subtitles?

For adult entertainment content, 15-17 characters per second is the industry standard across many markets. Children's content should stay at or below 13 CPS. Educational and accessibility-focused content benefits from 15 CPS or lower. Always account for script complexity: languages with logographic characters (Chinese, Japanese) or complex clusters (Thai, Khmer) require adjusted calculations based on information density per character.

Get started

Ship compliant, accessible subtitles across every platform.

Book a Demo