Most localized videos fail their audiences not because the translation is wrong, but because the subtitles are unreadable. Characters flash by too quickly, lines break mid-phrase, captions lack speaker identification, and formatting collapses when uploaded to a platform that silently strips your carefully authored styles. The result is a technically "localized" asset that frustrates viewers and undermines brand credibility.
This guide is a production-ready reference for building subtitles and captions that actually work, across formats, platforms, languages, and accessibility requirements. It covers the foundational distinctions between subtitle types, the timing and segmentation rules that govern readability, the accessibility mandates you must meet, platform-specific delivery considerations, and the quality checks that separate professional output from amateur work. If your team is scaling video localization across markets, explore how Ollang can streamline your subtitle and caption workflows.
Closed vs Open Captions: When Each Format Applies
The distinction between closed and open captions is fundamentally about viewer control and technical delivery.
Closed captions are delivered as a separate data layer, a sidecar file or embedded metadata track, that viewers can toggle on or off. They are the standard for broadcast television, streaming platforms, and most web video players. Closed captions preserve the viewer's choice and allow a single video file to serve multiple caption tracks in different languages.
Open captions (also called burned-in captions) are rendered directly into the video frames during encoding. They cannot be turned off. Open captions are essential when the delivery channel does not support sidecar tracks, the most common scenario being social media feeds where autoplay is muted and captions must be visible by default to capture attention.
Choosing between them
The decision is rarely about preference. It is driven by the delivery channel, the audience context, and accessibility obligations:
- Broadcast and OTT platforms almost universally require closed captions, often in specific formats mandated by the platform's delivery spec.
- Social media (Instagram Reels, TikTok, LinkedIn native video) either lack sidecar caption support or render it inconsistently, making burned-in captions the practical choice.
- Corporate training and LMS platforms typically support closed captions via WebVTT or SRT, and toggling is expected for multilingual learner populations.
- Live events and conference recordings may use open captions for archival versions to guarantee visibility regardless of player.
A common production pattern is to author captions as sidecar files first, then burn them in as a secondary rendering step for social cuts. This preserves editability and avoids maintaining two separate authoring pipelines.
Subtitles vs SDH: Terminology That Matters
The terms "subtitles" and "captions" are often used interchangeably, but they describe different things, and the distinction has real production implications.
Subtitles assume the viewer can hear the audio. They translate or transcribe dialogue only. They are the standard for interlingual use, a Japanese viewer watching an English-language film with Japanese subtitles.
Captions (and specifically SDH, Subtitles for the Deaf and Hard of Hearing) assume the viewer may not be able to hear the audio at all. SDH includes everything subtitles include, plus non-speech audio cues (a door slamming, music playing, a phone ringing), speaker identification, and descriptions of meaningful sound effects.
What SDH adds to the production scope
Producing SDH requires more than translating dialogue. Your captioning workflow must account for:
- Speaker identification: Labels like [NARRATOR], [DR. CHEN], or positional cues when multiple speakers overlap.
- Non-speech sound cues: Descriptions enclosed in brackets, [suspenseful music], [glass shattering], [crowd cheering], placed in sync with the audio event.
- Music identification: Song titles and lyrics when the music carries narrative meaning, versus a generic [music playing] tag when it does not.
- Tone and manner indicators: Cues like [whispering], [sarcastically], or [speaking in French] when the manner of speech is essential to comprehension.
SDH is required for accessibility-regulated content and is the expected standard for any content intended for broad public distribution.
Key Caption and Subtitle Formats
SRT: Simple, Universal, Limited
SubRip Text (SRT) is the most widely supported subtitle format. Its structure is minimal: a sequential index, a timecode range, and plain text.
1
00:00:01,500 --> 00:00:04,200
Welcome to the quarterly update.
2
00:00:04,800 --> 00:00:07,300
Let's start with the EMEA results.
SRT supports basic formatting (bold, italic, underline) through HTML-like tags, but rendering is inconsistent across players. It does not support positioning, alignment, font specification, or color, which means it cannot reliably handle speaker differentiation through visual styling. SRT uses comma-separated milliseconds in its timecodes, a detail that causes silent failures if a decimal point is substituted.
SRT is the right choice for simple subtitle delivery to platforms like YouTube, Vimeo, and most CMS-embedded players. It is not sufficient for broadcast, accessibility-regulated content, or any use case requiring positional control.
WebVTT: The Web Standard
Web Video Text Tracks (WebVTT) is the W3C standard for web-based video captioning. It is syntactically similar to SRT but adds critical capabilities:
- CSS-based styling: Font, color, size, and background can be controlled via ::cue pseudo-elements in the page's stylesheet.
- Positioning and alignment: Captions can be placed in specific regions of the video frame, essential for avoiding occlusion of on-screen text or graphics.
- Voice tags: <v Speaker Name> allows semantic speaker identification that assistive technologies can parse.
- Header metadata: The WEBVTT header can include descriptive metadata.
WEBVTT
00:00:01.500 --> 00:00:04.200 position:10% align:start
<v Narrator>Welcome to the quarterly update.
00:00:04.800 --> 00:00:07.300
<v CFO>Let's start with the EMEA results.
Note that WebVTT uses period-separated milliseconds, not commas. This is the most common conversion error when migrating from SRT.
WebVTT is the required format for HTML5 <track> elements and is supported by all modern browsers. It is the default choice for web-delivered content where accessibility compliance matters.
IMSC and TTML: Broadcast and Streaming Grade
IMSC (Internet Media Subtitles and Captions) is a constrained profile of TTML (Timed Text Markup Language), the W3C's XML-based subtitle standard. IMSC is the format required by many broadcast regulators and streaming platforms for professional delivery.
IMSC/TTML provides full control over:
- Font family, size, color, background, and opacity
- Precise region-based positioning
- Ruby annotations for CJK languages
- Bi-directional text for Arabic and Hebrew
- Multiple simultaneous caption regions
The tradeoff is complexity. IMSC files are verbose XML documents that require specialized authoring tools and careful validation. They are not hand-editable in a text editor the way SRT files are.
| Feature | SRT | WebVTT | IMSC/TTML |
|---|---|---|---|
| Styling control | Minimal | CSS-based | Full XML styling |
| Positioning | None | Yes | Yes (region-based) |
| Speaker identification | Manual text only | Voice tags | Semantic markup |
| CJK ruby support | No | No | Yes |
| RTL text support | Partial | Partial | Full |
| Broadcast acceptance | Rarely | Sometimes | Standard |
| Authoring complexity | Low | Low-Medium | High |
For enterprise localization at scale, the practical approach is to author in a rich format (IMSC or a proprietary tool format) and export to SRT or WebVTT for platforms that require simpler files. When you manage many language versions and output formats, authoring centrally and using a localization platform like Ollang reduces manual conversion and versioning work.
Rates and Pricing: What You Actually Pay For
Rates for subtitles and captions vary across providers, languages, and deliverables. To scope budgets accurately, align on the service bundle and the unit of measure up front.
- Common billing units:
- Per video minute for end-to-end subtitling (transcription, translation, timing, QC)
- Per word for translation-only components
- Per subtitle event or per line in some regions
- Hourly for engineering, format conversions, or complex retiming
- Scope factors that drive cost:
- SDH vs. dialogue-only subtitles (speaker IDs and non-speech cues add effort)
- Audio quality and the need for transcription cleanup
- Domain complexity and required terminology research
- On-screen text (OST) that needs translation and compositing
- Platform deliverables (SRT, WebVTT, IMSC/TTML, SCC) and per-aspect-ratio burn-ins
- Accessibility compliance reviews and second-pass linguistic QA
- Turnaround speed, live vs. prerecorded, and change management after picture lock
- Workflow components that should be explicit in a quote:
- Spotting/timing and segmentation to CPS targets
- Translation with condensation for reading speed
- SDH authoring (speaker IDs and sound cues)
- QC against style guide and platform specs
- Format exports and validation, plus burned-in renders where needed
- Red flags in low quotes:
- No CPS enforcement or segmentation standards
- Machine captions or raw MT with minimal post-editing
- Omitted SDH cues or inconsistent speaker identification
- Single-output pricing when you require multi-format delivery
For predictable budgeting, define your style guide and deliverable list first, then request a bundled per-minute quote for each language. Include room for editorial changes after initial delivery; small timeline edits ripple through timecodes and re-exports.
Timing Rules: Duration, Gaps, and Frame Accuracy
Subtitle timing is where readability is won or lost. Even a perfect translation becomes useless if it appears too briefly, lingers too long, or collides with adjacent cues.
Minimum and maximum display durations
- Minimum duration: A subtitle should remain on screen for at least one second, even for very short utterances. Anything below 0.7 seconds creates a flash that most viewers cannot process.
- Maximum duration: A single subtitle should not exceed seven seconds on screen. Beyond this, viewers lose track of whether the text has changed, and the subtitle feels "stuck." For content with long pauses in dialogue, the subtitle should disappear and reappear rather than persist.
In/out gaps between consecutive subtitles
A minimum gap of two frames (approximately 80ms at 25fps) between consecutive subtitles is the widely accepted standard. This gap gives the viewer's eye a perceptible "blink" that signals new text has appeared. Without it, viewers may not realize the subtitle has changed, especially when the new text is similar in length and position to the previous one.
Some style guides specify gaps as high as 120ms or even 200ms. The right value depends on the frame rate of the source video and the density of the dialogue.
Frame rate and timecode alignment
Subtitles must be authored to the video's native frame rate. A subtitle timed to 25fps will drift when played against 23.976fps content, by roughly four seconds per hour. This is one of the most common causes of "subtitles out of sync" complaints and is entirely preventable with proper source metadata.
For drop-frame timecode (common in NTSC-origin content at 29.97fps), subtitle tools must account for the timecode numbering scheme or risk cumulative drift.
Segmentation and Line-Break Standards
How you break text across lines and across subtitle events has a measurable impact on reading comprehension. Poor segmentation forces the viewer to mentally reassemble phrases, which competes with the visual content for cognitive attention.
Core segmentation principles
- Break at syntactic boundaries. Keep noun phrases, verb phrases, and prepositional phrases intact. Never break between an article and its noun, between a preposition and its object, or between an auxiliary verb and its main verb.
- Two lines maximum per subtitle event. Three-line subtitles are acceptable only in specific broadcast contexts (teletext-era legacy systems) and should be avoided for digital delivery.
- Top-line / bottom-line balance. When a subtitle spans two lines, the bottom line should be equal to or longer than the top line. This creates a visually stable pyramid shape and avoids the top line occluding more of the image than necessary.
Line length limits
Maximum characters per line vary by language and delivery context. A common baseline is 42 characters per line for Latin-script languages, but this is not universal:
| Language group | Recommended max characters per line |
|---|---|
| English, Spanish, French, German | 37-42 |
| Japanese | 13-16 (full-width characters) |
| Korean | 16-18 |
| Arabic, Hebrew | 35-42 |
| Chinese (Simplified/Traditional) | 14-16 |
These limits exist because subtitle text must remain legible at the video's display resolution. Exceeding them results in text that is either truncated, scaled to an unreadably small size, or wrapped unpredictably by the player.
Handling text expansion
Translation from English into languages like German, French, or Finnish routinely produces text that is 20-35% longer than the source. This expansion must be absorbed through a combination of:
- Condensing the translation (conveying meaning with fewer words, not omitting meaning)
- Splitting a single source subtitle into two target-language events
- Adjusting timing to allow slightly longer display
Condensation is a translation skill, not an editing afterthought. Subtitle translators must be briefed on character limits and reading-speed targets before they begin work, not asked to trim after the fact.
Reading Speed Limits by Content and Audience
Reading speed, measured in characters per second (CPS), is the single most important readability metric for subtitles. A subtitle that exceeds the viewer's comfortable reading speed forces a choice between reading the text and watching the video. Neither outcome is acceptable.
Industry benchmarks
- Adult entertainment (drama, documentary, corporate): 15-17 CPS is the widely accepted comfort zone. Netflix's Timed Text Style Guide specifies a maximum adult reading speed of 17 CPS for most languages.
- Children's content (ages 6-12): 13 CPS maximum. Younger audiences read more slowly and need more time to process both text and image.
- Content for language learners: 12-14 CPS, with simpler vocabulary and shorter subtitle events.
- Fast-paced content (news tickers, sports commentary): Reading speed limits may be relaxed to 20 CPS, but comprehension drops significantly.
CPS versus words per minute
Some legacy style guides use words per minute (WPM) as the reading-speed metric. CPS is more precise because word length varies dramatically across languages. A "word" in German averages significantly more characters than a "word" in English, making WPM comparisons across languages unreliable. CPS normalizes this.
Practical implications
When dialogue is too dense to subtitle within CPS limits, the subtitle translator must condense. This is not optional, it is a core competency of professional subtitle localization. The alternative is subtitles that viewers cannot read, which defeats the purpose of the localization entirely.
If your team is navigating these tradeoffs across dozens of language pairs and content types, see how Ollang's localization platform handles reading-speed compliance at scale.
