Compare two SRT files before replacing a subtitle track

Compare the exported files, then review the changes

To compare two SRT files, keep the previously approved export as your baseline, compare it with the proposed replacement, and classify each difference as text, timing, cue structure or file formatting. Then check the changed passages against the matching video. A comparison finds differences; it does not decide whether they are correct.

This is useful when an editor returns a revision that is supposed to fix one name, but the export also changes numbering or timing. You need a clear answer before replacing the delivered track: which changes were requested, which are harmless for this destination, and which still need review? Use recordings and subtitle files you own or are authorized to process.

Choose a trustworthy baseline

Use the exact subtitle file that was approved or delivered, rather than an older project export with a similar filename. Record the video revision, spoken soundtrack, subtitle language and track purpose beside it. A full caption track and a dialogue-only translation are different deliverables even when their filenames share a language code.

Save the candidate under a separate name. Preserve unsaved editor work before exporting either version. For example, card-demo-cut03.en.approved.srt and card-demo-cut03.en.candidate.srt make the review direction explicit. A newer modification date alone does not identify the approved file.

Write the expected change first: “Correct blue to green in the first cue and divide the long second cue; keep the last cue unchanged.” If the video itself was recut, stop treating the task as a small text revision. Establish which video each file matches before interpreting timing differences.

Use a local text comparison as a first pass

An SRT is a text file arranged into numbered blocks with a start time, end time, caption text and a blank separator. The Library of Congress describes this structure. Open both files in a local text editor that can compare files, keeping the approved version on one side and the candidate on the other. Avoid uploading private transcript contents to an online comparison service merely for convenience.

If Git is already installed, its documented --no-index option can compare two local paths without creating a repository. Run the command below from their folder, replacing approved.srt and candidate.srt with your actual filenames. It reads them and prints a comparison; it does not replace either file. If Git is unavailable, use a local editor comparison instead.

In ordinary patch output, removed lines start with a minus and added lines with a plus; the file headers and location markers provide context. Git reports exit status 1 when differences are found, so that result alone is expected here. Read any error message rather than treating every nonzero result as a valid comparison. Keep whitespace visible for the first pass: line breaks and blank separators can matter in subtitles.

git --no-pager diff \
  --no-index -- \
  "approved.srt" \
  "candidate.srt"

Separate four kinds of difference

Text changes include words, punctuation, speaker labels and meaningful sound descriptions. Check meaning first, especially a missing negation, changed quantity or proper name. A one-character change can matter more than dozens of renumbered blocks.

Timing changes affect a cue’s start, end or both. If both endpoints move by the same amount, the duration stays the same but the caption appears earlier or later. If only one endpoint moves, the duration changes. Check adjacent cues for unintended overlaps or gaps and listen to the corresponding passage.

Structural changes split one cue into several, join several cues, insert a cue or remove one. These can renumber every later block. Do not assume old cue 12 and new cue 12 contain the same passage. Match the words, nearby timing and neighboring content, then record the relationship explicitly. Repeated phrases such as “thank you” need extra context.

File-format differences include line endings, encoding and blank lines. They can make a text comparison look dramatic without changing the spoken words, but they are not automatically safe to discard. Keep the originals, investigate garbled characters separately, and validate the actual delivery file. A view that ignores whitespace is a convenience for investigation, not an approval check.

Read the approved example

The following invented card demonstration has three cues. Assume a reviewer has confirmed that the recording says “green,” so the first cue needs that correction. The second cue may be split at a separately verified fourteen-second phrase boundary. The final cue is already approved and should stay unchanged. These are teaching assumptions, not observations from a tested recording.

Keep this baseline intact. Its three blocks give you a compact record of the original words and intervals.

1
00:00:10,000 --> 00:00:12,000
Place the blue card.

2
00:00:12,000 --> 00:00:16,000
Keep the printed side up.
Wait for the signal.

3
00:00:18,000 --> 00:00:20,000
Turn the card.

Inspect the candidate, including the quiet changes

The candidate below contains the requested color correction and the requested split. It also moves the last caption by 400 milliseconds. The final cue still lasts two seconds, so a duration-only check would miss that shift. Its new number, four, is expected after the split; its new timing is a separate change.

The split itself needs two checks: both original phrases remain in order, and the new boundary matches the approved speech transition. The cue count rises from three to four, but the count alone proves neither text preservation nor correct timing. No words were lost in this example; a real review must establish that rather than assume it.

1
00:00:10,000 --> 00:00:12,000
Place the green card.

2
00:00:12,000 --> 00:00:14,000
Keep the printed side up.

3
00:00:14,000 --> 00:00:16,000
Wait for the signal.

4
00:00:18,400 --> 00:00:20,400
Turn the card.

Make an explicit change decision

Record old cue 1 to new cue 1 as the approved color correction. Record old cue 2 to new cues 2–3 as the structural split, with the fourteen-second boundary requiring its listening check. Record old cue 3 to new cue 4 as unchanged text with an unexpected +0.400-second start and end shift.

Hold that timing change until its reason is established. If it was accidental, restore the approved interval in a new candidate. If the editor intended a sync correction, verify it against the recording and update the change request. Do not accept every difference just because one requested correction is present.

After any repair, export again and compare that new export with the retained baseline. Check that the repair did not remove another approved manual edit. Keep a short decision log with the passage, changed fields, reason and status; this can be a plain local document. It is a human review record, not an automatic Polyglot report.

Keep text comparison and playback review together

Polyglot can import an SRT, let you review and edit subtitle text and timing, and export a separate file. Use the local comparison described here alongside that workflow. This guide does not rely on a built-in two-file diff, automatic cue matching or a merge command.

W3C’s caption guidance emphasizes accurate content and synchronization and warns that automatic captions need correction. A clean file comparison cannot establish either accuracy or synchronization by itself. Listen before and after changed passages at normal speed, with temporary player subtitle delays disabled, and inspect the picture for reading or placement problems.

Review each language independently. A source correction can require translation changes even when that translated file has no textual difference yet. Likewise, a source cue split does not establish where a translated phrase should divide. Keep unresolved language files pending and follow the separate source-correction workflow for dependent deliveries.

Approve the replacement that viewers will receive

Before delivery, reopen the actual replacement export, validate its structure and confirm all differences have a recorded decision. Check the complete intended track with its exact video, not only the first corrected cue. Retain the old file as superseded until replacement is confirmed.

Use the recipient’s supported procedure to replace or select the approved track. Then verify the viewer-facing language, corrected wording, changed timing boundaries and final cue. An identical local file can still be paired with the wrong video or the wrong track selection.

Finish the record with the approved filename, matching video revision, language and destination check. If only the local file was reviewed, leave destination acceptance pending. The useful result is an explainable replacement: every intended edit survived, every unexpected difference was resolved, and the recipient is using the version you approved.

Keep exploring.