Validate an SRT file before delivery

Check the file, its contents and its destination

To validate an SRT file, check that every subtitle block has a number, a readable start and end time, text and a blank separator. Then compare the complete set of cues with your original and play the exported file beside the final video. These checks answer different questions: can the software read it, did anything change, and does the viewer receive the intended captions?

A subtitle validator can flag mechanical errors, but a clean result does not establish accurate speech, good translation or comfortable reading time. The Library of Congress describes SRT as widely used but not well standardized. A file accepted by one reader can still need adjustment for another destination. Use this workflow with recordings and subtitle files you own or have permission to edit and distribute.

Keep an untouched copy and a cue inventory

Before fixing anything, save the received SRT separately and identify the exact video edit it accompanies. Work on a copy with a different filename. If an editor offers to repair everything automatically, first find out whether it will renumber, merge, remove or retime cues. A simpler-looking file can hide missing dialogue.

Record the number of actual cue blocks, the first and last cue text, and their timestamps. The final numeric identifier is not a reliable cue count: a file could contain 42 blocks with a last identifier of 45. Preserve the original identifiers in your comparison notes so a reviewer can still locate the reported problem. If the file cannot be parsed, inspect its blocks as plain text before trusting an importer’s count.

Also note intentional overlaps, multiline captions and any unusual characters. These are the parts most likely to be mistaken for cleanup opportunities. An inventory is a small external review note you maintain, not a special Polyglot report.

Read the four parts of an SRT block

Open the working copy in a plain-text editor. Check the actual filename, including its final extension: adding .srt to a rich-text document does not convert its contents. A conventional block contains a numeric counter, a timing line, one or more lines of subtitle text and then an empty line before the next counter.

Write conventional SRT timecodes as HH:MM:SS,mmm, with three millisecond digits. The arrow is two ordinary hyphens followed by a greater-than sign: -->. In 00:00:07,250, the last group means 250 milliseconds, not frame 250. Check for a typographic arrow, a missing digit or a minute/second field outside 00–59. A blank line belongs between cues; an ordinary line break can belong inside the caption.

This small, original example is a complete two-cue excerpt from an imagined paper-folding demonstration. Both captions have positive durations and a blank separator. Their timings are illustrative, not measurements from a real recording.

1
00:00:01,000 --> 00:00:03,000
Fold the paper in half.

2
00:00:03,500 --> 00:00:05,500
Open it again.

Repair a specific error instead of guessing

The next version contains the same words but has two defects: cue 1 has no blank separator before cue 2, and cue 2 ends before it starts. A reader may reject the file; a tolerant reader may interpret malformed content differently. Neither outcome tells you what the intended end time was.

Restore the missing separator, then check the end time against an approved earlier file or the matching video. For this fictional example, the valid excerpt above supplies the reference of 00:00:05,500. In a real project, do not simply swap the start and end or invent an extra two seconds. If the intended timing is unknown, keep that cue pending for review.

After each repair, inspect the affected block and both neighbors. A validator that stops at the first failure may reveal another problem only after the first is corrected. Continue until the entire file is read successfully, then compare its contents rather than assuming the absence of an error means nothing was lost.

1
00:00:01,000 --> 00:00:03,000
Fold the paper in half.
2
00:00:03,500 --> 00:00:03,200
Open it again.

Separate structural failures from review warnings

An end time at or before its start gives a cue no usable positive duration. Missing text, an unrecognizable timestamp or a missing cue boundary also needs investigation. Repeated identifiers deserve attention because they make cue references ambiguous and some importers reject them. Polyglot’s SRT import checks include duplicate identifiers, empty text and invalid timing; it rejects malformed input rather than intentionally skipping a bad cue.

Other flags need context. A gap may represent silence. Two cues may overlap because two sounds occur together. A long line may be readable on one screen and awkward on another. Do not remove an overlap or shorten a caption solely to make every warning disappear. Listen, inspect the picture and check the destination requirements. Polyglot preserves overlaps in imported SRT files; that does not guarantee every player presents them well.

For a newly prepared delivery, sequential numbering makes inspection easier. If you renumber an existing file to meet a recipient’s requirement, retain a before-and-after mapping and verify that text and timing are unchanged. A skipped counter is not proof that a subtitle is missing; compare the actual blocks with the source inventory.

Compare the repaired export with the baseline

Reopen the exported SRT as plain text and in your subtitle reader. Compare the full cue count, identifiers, order, start times, end times and text against the untouched file. Account for each intentional change. Repairing a separator should not translate a sentence, move a later scene or erase an accent.

If the original was too malformed for a trustworthy automated comparison, use its visible blocks and a known-good earlier export as references. Check the first and last cues, every repaired passage and the surrounding blocks, then complete the rest of the inventory. A count match alone is insufficient: one missing cue and one duplicate could cancel each other out.

Keep structural repair separate from rewriting. If meaning or timing also needs editorial work, record it as a second change with its own evidence. This makes it possible to tell a necessary file repair from a deliberate subtitle revision.

Confirm the actual destination can use it

Read the receiving platform’s current file requirements. For example, YouTube specifies basic SRT in plain UTF-8 and does not recognize SRT styling markup. That is a concrete destination rule, not evidence that every SRT reader has identical restrictions. If the recipient asks for WebVTT, convert and validate that output; renaming the extension is not conversion.

Load the exact delivery file with the final video in the intended player or a permitted draft upload. Select the correct language track and check the beginning, end, repaired cues, overlaps, dense passages and accented text. Then review the complete track for missing content and synchronization. If you only checked a local player, record destination acceptance as pending.

W3C’s caption guidance emphasizes accurate speech and the non-speech information needed to understand the recording. Syntax validation cannot decide whether a missing “not” reverses a sentence or whether an important sound needs a caption. Keep language, accessibility and playback review explicit before calling the subtitles ready.

Make the handoff easy to verify

Keep the delivered SRT beside a short note naming the video revision, language, actual cue count, repairs and destination check. Record pending items honestly. Retain the untouched original and the reviewed export until the recipient confirms the correct file is in use.

The checklist below is a suggested manual handoff record. It distinguishes structural acceptance from the work that needs a person and a real player; none of its boxes should be marked complete merely because a file opened.

Video edit: __________
Language: ____________
Delivery SRT: ________
Actual cue count: ____

[ ] Full file parses
[ ] Every cue accounted for
[ ] Repairs documented
[ ] Meaning reviewed
[ ] Final player checked

Pending items: _______

Keep exploring.