Subtitle SRT Validator — Cue Timing and Structure

An SRT validator examines a SubRip subtitle file for structural mistakes before the track is uploaded to an editor, player, or caption service. Paste the text or select an SRT file to check cue numbers, timestamp syntax, positive durations, chronological order, blank captions, and overlapping cues. Findings are tied to source lines, and the report distinguishes errors from warnings. Validation checks file structure, not whether words match speech or appear at a comfortable pace. A structurally valid subtitle file still needs playback and language review.

SRT Validator At a Glance

How SubRip files represent captions

An SRT file usually repeats three parts: a cue number, a time range, and one or more lines of subtitle text. A blank line separates one cue from the next. A standard timing line looks like 00:00:04,250 --> 00:00:06,900, with a comma before the millisecond fraction. Editors often accept minor deviations, but other applications reject or misinterpret them. This validator uses the standard structural form to make problems explicit rather than guessing what a media player may tolerate. It preserves the supplied text and reports where it found each timed block.

Cue numbering and missing entries

Cue numbers normally start at one and increase consecutively. A file that jumps from cue two to cue four might still display in some players, but the discontinuity can reveal a deleted segment or a damaged export. With strict numbering enabled, the checker reports a mismatched index using the corresponding source line. The setting can be relaxed for inspection of unusual imports, but this does not rewrite numbering in the input. Before fixing indices, inspect the associated time intervals to ensure no subtitle segment has actually gone missing. Renumbering alone cannot recreate a lost line of dialogue.

Milliseconds and timestamp separators

SRT timing requires hours, minutes, seconds, and three millisecond digits. It uses a comma as the decimal separator; WebVTT uses a period instead. Replacing only the filename extension will not convert these conventions correctly. A timestamp like 00:01:15,500 is one minute and fifteen and a half seconds, while 00:01:75,500 is structurally invalid because the seconds field is outside 00–59. The checker rejects invalid components rather than allowing JavaScript date parsing to normalize them silently. This distinction matters when a file is generated automatically or assembled from spreadsheet cells.

Duration must remain positive

A subtitle ending at the same instant it begins has zero display time, and a cue with an earlier end than start is impossible to present as written. The validator flags both as errors. Very short but positive durations are not automatically errors because some captions intentionally show brief effects or interjections, but they may deserve editorial attention. Conversely, extremely long intervals can occur in poorly segmented automated outputs. Review those against video playback and the expected reading pace rather than applying a universal duration threshold that might misclassify unusual but intentional captions.

Overlaps and chronological ordering

Two captions may intentionally overlap in advanced subtitle workflows, but ordinary single-track SRT often expects a straightforward sequence. This validator warns when a cue begins before the previous cue ends and reports an error when the sequence moves backward in start time. The overlap warning is not an automatic instruction to trim either caption; doing so could hide speech or leave a gap. Use the playback timeline to understand whether the overlap is intentional or an export defect. Captions that are numbered correctly can still have incorrect chronological timing if segments were shuffled during editing.

Worked example: identify a malformed cue

Consider a file whose first cue displays 00:00:01,000 --> 00:00:03,200 and whose second cue starts at 00:00:02,800. Both timestamps are individually valid, yet the second cue begins 400 milliseconds before the first ends. The report marks that as an overlap warning. If the second line instead uses 00:00:75,000, it produces a time-format error. If the index is four instead of two, strict numbering produces another error. Keeping these findings separate helps an editor correct exactly the defect observed rather than replacing the whole subtitle file.

Preserve multiline captions

A cue may contain a subtitle divided across two or more visual lines. The validator keeps the newline characters in the cue text rather than compressing all lines into a single sentence. The distinction can matter for speaker turns, intended reading breaks, and intentional emphasis. However, line length and per-cue reading speed are separate accessibility questions. A reading level analyzer can help evaluate the complexity of accompanying prose, but it does not judge caption timing or substitute for watching the media. Validate the text presentation in the actual player before release.

Import files with care

A byte-order mark, Windows CRLF line endings, and Unix LF line endings can appear in subtitle files from different systems. The validator normalizes those boundaries during inspection and imposes a file-size and cue-count limit. It does not fetch remote URLs or attempt to decode arbitrary binary data. If an editor exports in a legacy character encoding, visible characters may already be damaged before the script can inspect them; choosing the correct source encoding and exporting UTF-8 is a separate task. Compare accent marks and non-Latin text after conversion because syntactically valid timestamps say nothing about character integrity.

Error reports are not automatic repairs

The downloaded JSON contains cue details, source line references, and severity levels to support manual review. It does not silently rewrite timestamps, renumber records, or delete blank cues. Automatic repair can be dangerous when a line is missing because a fabricated index or time makes the file appear cleaner than the underlying caption data. Fix the original track in its editing source where possible and export a fresh SRT. Run the validator again and compare the issue count, then verify the corrected captions while playing the video from the beginning to its final seconds.

Separate structural checks from language checks

An SRT file can pass every structural test while containing misheard names, incorrect terminology, or entirely inaccurate translations. A caption may also be delayed by several seconds relative to the audible dialogue despite having perfectly increasing timestamps. These are media-quality problems, not parser errors. Review with a person who understands the spoken language and, where possible, subject-specific vocabulary. If a narrator refers to a chart or on-screen instruction, the caption may need contextual attention beyond exact speech transcription. Structural validation gives editors one reliable layer of evidence, but not a certification of caption quality.

When warnings deserve prioritization

Prioritize hard errors that prevent a player from interpreting a track: malformed timing arrows, impossible timestamps, and missing caption text. Then review warnings for overlaps and unusual cues, especially around scene transitions or rapid dialogue. A useful practice is to keep a revision log that records what was changed and why. Do not fix overlapping captions by truncating them uniformly; an edit that saves one interval can make another subtitle unreadably short. Play the adjusted section at normal speed, then check adjacent cues for new gaps or collisions before approving the track.

Accessibility and editorial review

Readable captions require appropriate timing, accurate wording, speaker attribution when relevant, and visual placement that does not obstruct essential content. A validator can point out impossible time ranges but cannot measure a viewer's comprehension. Consider dialogue speed, onscreen action, and language complexity as part of the accessibility review. If the track accompanies a long presentation, sample ordinary sections and known difficult moments rather than checking only the opening. Document the player or service used during verification because line breaking and subtitle styling can differ after upload.

Integration with subtitle conversion

Validation is an appropriate checkpoint before converting SRT into another format or shifting every cue in time. If errors remain, a converter should stop rather than produce output that appears successful but contains ambiguous intervals. Correct the source, validate again, and preserve the original version for comparison. When the corrected file is converted, repeat playback testing because another format may interpret formatting, position cues, and line breaks differently. Maintaining separate source, validated, and exported copies makes it possible to investigate a later synchronization complaint without guessing which edit introduced the problem.

Technical bounds and inspection scope

Input is limited to 1.5 megabytes and 5,000 timed blocks to keep the analysis predictable. The checker inspects common SRT structure; proprietary subtitle extensions, uncommon style directives, and embedded formatting conventions may require an application-specific parser. Warnings reflect the observed text, not an attempt to prove universal player compatibility. If no valid cues can be parsed, the report records that result rather than claiming a completed validation. File names and empty cue groups are not trusted as proof that content is SubRip; the actual cue syntax is what determines the diagnostic outcome.

Frequently Asked Questions

Conclusion

An SRT validator is best used before every significant subtitle conversion, timing shift, and publication handoff. Resolve structural errors, consider overlap warnings in context, and finish with an audio-synchronized playback review.