SRT Subtitle Validator Guide: Fix Subtitle Files Before They Fail

Subtitles look simple: a few lines of text that appear and disappear in time with a video. But the file behind them follows a strict format, and a single mistake — a missing blank line, a wrong timestamp, an out-of-order cue — can make a video player ignore the whole file or display captions at the wrong moments. By the time a viewer notices, the damage to their experience is already done.

An SRT validator checks a subtitle file against the format rules and reports the problems, so you can fix them before publishing. The SRT Subtitle Validator does this check for you. This guide explains the SRT format, the errors validators catch, and how to fix the most common ones.

The SRT format, cue by cue

An SRT file is plain text divided into blocks called cues. Each cue has four parts. First, a sequence number, starting at 1 and increasing by one for each cue. Second, a timing line with a start time, an arrow, and an end time, written as hours, minutes, seconds, and milliseconds, separated by colons and a comma: 00:00:01,000 --> 00:00:04,000. Third, one or two lines of subtitle text. Fourth, a blank line that separates this cue from the next.

That blank line is not decoration; it is how players know where one cue ends and the next begins. Without it, two cues merge into one, and the timing breaks. Similarly, the arrow must be exactly two hyphens and a greater-than sign, surrounded by spaces, and the milliseconds must use a comma, not a full stop. Players that expect a comma may reject a timestamp written with a full stop, even though a human reader would understand it.

Text lines have their own conventions. Most style guides recommend a maximum of two lines per cue, and many players wrap or cut longer text. A cue should stay on screen long enough to read, usually at least one second, and not so long that it lags behind the speech. These are guidelines rather than strict format rules, but a good validator flags them as warnings, because they affect readability even when the file technically loads.

Errors a validator catches

The most serious errors are structural: a missing sequence number, a malformed timestamp, a missing blank line, or cues in the wrong time order. A timestamp where the end time comes before the start time is a common example, often caused by a typing slip. Overlapping cues, where one cue starts before the previous one ends, are another: some players handle them gracefully, but many show only one of the two, so the viewer misses text.

Timing errors are the next category. A cue with zero duration, where start and end times are identical, flashes past too quickly to read. A cue that starts before the previous cue ends creates an overlap. A gap of many minutes with no cues is not an error, but it is worth checking, because it may mean a section of dialogue was missed. Validators also check numbering: if the sequence jumps from 3 to 5, a cue was probably deleted without renumbering, and while many players ignore the numbers, some do not.

Encoding errors are subtler. SRT files should use UTF-8 encoding so that accented characters and non-Latin scripts display correctly. A file saved in another encoding may show replacement characters or question marks for those letters. If your subtitles contain characters outside basic English and they display incorrectly, encoding is the first thing to check.

Worked example: validating a short file

Consider this sample file with two cues:

1 00:00:01,000 --> 00:00:04,000 Hello, and welcome to the show.

2 00:00:05,500 --> 00:00:08,000 Today we visit the old harbour.

Check the first cue. Its sequence number is 1, its timing line is well formed, and its duration is 4,000 minus 1,000 milliseconds, which is 3,000 milliseconds, or 3 seconds — a comfortable reading time for a short line. The blank line separates it from the second cue. The second cue is numbered 2, its timing is well formed, and its duration is 8,000 minus 5,500 milliseconds, which is 2,500 milliseconds, or 2.5 seconds, also reasonable. The cues do not overlap, because the second starts at 5.5 seconds, after the first ends at 4 seconds. This file should pass validation cleanly.

Now introduce an error: change the second cue's start time to 00:00:03,500. The second cue would then start before the first cue ends at 4 seconds, creating an overlap of 0.5 seconds. A validator would flag this, and the fix is to move the second cue's start to at least 4 seconds, or to shorten the first cue's end time. This kind of small timing slip is exactly what validators are for, because it is easy to introduce while editing and hard to spot by eye.

Fixing common problems

When a validator reports an error, fix it at the source rather than patching around it. Renumber cues from the start if the numbering is broken. Correct timestamps by listening to the audio, not by guessing, because a caption that appears early or late is worse than one that is slightly short. If two cues overlap, decide which one should move: usually the later cue starts too early, or the earlier cue runs too long.

For files with many errors, it is often faster to re-export from the subtitling tool that created the file than to hand-edit dozens of cues. If you must hand-edit, use a plain text editor, not a word processor, because word processors can change straight quotes, alter encoding, or insert invisible formatting that breaks the file. Save as plain text with UTF-8 encoding.

After fixing, validate again. A single pass rarely catches everything, because fixing one timing error can reveal another, such as a new overlap created by moving a cue. Two passes — validate, fix, validate — are a sensible minimum before publishing.

Subtitling involves several related checks. The Subtitle Reading Speed Checker measures whether each cue stays on screen long enough to read, and the Subtitle Line Break Formatter helps split long lines into readable two-line cues. For a guide on how long a text takes to read, see the Academic Reading Time Calculator Guide.

Validating subtitles takes minutes and saves viewers from missing dialogue, mistimed captions, or a file that fails entirely. Learn the cue structure, run the validator before every publish, fix errors at the source, and validate once more after fixing. Your viewers may never notice the work, and that is precisely the point.