Understanding easycaptns Requirements: Your Complete Guide

Before a caption file ever reaches a viewer, it has to satisfy a surprising number of technical requirements. Get them right and captions load cleanly, sync perfectly, and display correctly on every device. Get them wrong and you see the tell-tale failures: captions that do not appear at all, garbled accented characters, timing that drifts, or an upload rejected by a platform with a cryptic error. This guide walks through the concrete technical requirements a caption file must meet, so your work displays the way you intended wherever it lands.

Want expert help putting this into practice? EasyCaptions can guide you through it.

Getting the file format right

The first requirement is choosing a caption format the destination actually accepts. The two you will meet most often are SRT and WebVTT. SRT (SubRip) is the simplest and most widely supported: a plain-text file with numbered cues, timestamps, and text. WebVTT (.vtt) is the standard for the web and HTML5 video, and it supports styling, positioning, and metadata that SRT cannot.

Beyond these, broadcast and professional contexts use formats like SCC, EBU-STL, and TTML/IMSC, each with its own strict rules. The practical requirement is simple: check what your platform wants before you export. Uploading an SRT where a VTT is required, or a broadcast format to a web player, is a frequent and avoidable cause of captions silently not showing up.

Timing and timestamp precision

Related: easycaptions - expert advice for effective captioning.

Every caption cue carries an in-time and an out-time, and formats are strict about how these are written. SRT uses a comma before milliseconds (00:01:23,400) while WebVTT uses a period (00:01:23.400). Mixing them up is one of the most common reasons a file fails to parse. The timestamps must also be in chronological order, and cues generally should not overlap unless the format explicitly supports simultaneous captions.

The timing requirements that matter most in practice:

• Millisecond precision, since rounding to whole seconds causes visible sync drift.
• Cues ordered from earliest to latest with no timestamp running backward.
• A minimum on-screen duration, typically at least one second, so captions are readable.
• Frame-rate awareness for broadcast, where timecode must match the video's frame rate exactly.

If captions appear consistently early or late, the usual culprit is a frame-rate mismatch between the caption file and the video, not the individual timestamps.

Text length and line requirements

Readability requirements are as real as technical ones, and some platforms enforce them. The widely used limits are a maximum of two lines per caption and roughly 32 to 42 characters per line, though broadcast standards may cap it lower. These are not arbitrary. A caption longer than two lines covers too much of the picture, and one that exceeds a comfortable character count either gets cut off or forces an unreadable reading speed.

Reading speed itself is a requirement in many delivery specs, commonly expressed as characters per second, with a typical ceiling around 17 to 20. If a cue's text is too long for its duration, it violates that limit and must be split into two cues or shortened. Building these limits into your workflow from the start saves a painful reformatting pass at the end. A caption that satisfies the character-count rule but violates the characters-per-second ceiling is still non-compliant, so treat the two requirements as a pair: length and duration together determine whether a cue is actually readable, and a good editor flags both as you work.

Encoding, characters, and the invisible failures

See also: EasyCaptions: A Complete Guide to Captioning for Accessibility and Compliance.

One of the most overlooked requirements is character encoding. Caption files should be saved as UTF-8, ideally without a byte-order mark unless the platform expects one. When a file is saved in the wrong encoding, accented letters, curly quotes, and non-Latin scripts turn into garbage symbols, and the failure often does not appear until a viewer with a different setup sees it.

Related requirements that quietly break files:

• Consistent line endings, since some strict parsers dislike mixed Windows and Unix breaks.
• No stray blank lines inside a cue, which can split one caption into two malformed ones.
• Escaping or avoiding characters that a format treats as markup, such as angle brackets in some VTT contexts.
• A correct file extension that matches the actual format inside.

These issues are frustrating precisely because the file looks fine in a text editor and only fails on the target platform. Validating before upload is the cure.

Platform-specific rules you cannot ignore

On top of the format standards, individual platforms layer their own requirements. Video sites may cap file size, require a specific language code in the filename, or expect the caption filename to match the video filename with a language suffix. Streaming services often demand a particular profile of TTML with exact positioning and styling constraints. Social platforms may only accept burned-in open captions in certain posting flows, meaning the requirement is a rendered video rather than a sidecar file at all.

The safe habit is to read the platform's caption documentation once, note its specific requirements, and keep that note handy. A caption file that is technically perfect against the general standard can still be rejected for missing a platform's particular language-tag or naming convention.

A pre-delivery checklist

Pulling it together, run every caption file through the same checks before you consider it done:

• Format matches what the destination accepts (SRT, VTT, TTML, and so on).
• Timestamps use the correct separator and run in chronological order.
• Frame rate matches the video for broadcast delivery.
• No cue exceeds two lines or the platform's character limit.
• Reading speed stays within the specified characters-per-second ceiling.
• File is saved as UTF-8 with consistent line endings.
• Filename and language tags follow the platform's naming rules.

Meeting these requirements is unglamorous but decisive, because it is the difference between captions that just work and captions that fail silently in front of the exact viewers who need them. Tools like EasyCaptions handle much of this automatically, exporting valid, correctly encoded files in the format your platform expects, so you can focus on getting the words and timing right rather than debugging a parser error. Treat the requirements as a checklist rather than an afterthought, and your captions will display cleanly everywhere you publish.