How to edit an SRT file, and what breaks when you do

What is actually in the file

There is no header, no metadata and no escaping. The whole format is one block repeated until the file ends, and every part of the block matters:

• A cue number on its own line, counting up from 1
• A timecode line: the start time, a space, two hyphens and a right angle bracket, a space, then the end time
• Each time written as hours, minutes, seconds, then a comma and three digits of milliseconds, every field zero-padded
• One or two lines of text. Two is the practical maximum, because a third covers too much of the picture
• A blank line. This is what tells the parser the cue has ended, and it is the part most often lost

The four things that make a player reject it

Most broken subtitle files are broken in one of four ways, and all four come from hand-editing.

A full stop instead of a comma before the milliseconds. SRT uses a comma and WebVTT uses a full stop, which is the commonest mistake when someone has been working in both formats, or has renamed a file rather than converting it.

A malformed arrow. It is exactly two hyphens and a right angle bracket, with one space on each side. An en dash substituted by a word processor looks nearly identical and parses as nothing.

A missing blank line between cues, which merges two captions into one that then has the wrong timing for both halves. Or the opposite, a stray blank line inside a cue, which truncates it.

Wrong text encoding. Save as UTF-8, without a byte order mark if your editor offers the choice. A file saved as UTF-16 or in a legacy codepage either fails to load or turns every accented character into garbage, and it looks perfectly fine in the editor that produced it.

Fixing timing without editing every line

If the subtitles are consistently early or late by the same amount, every timecode in the file needs the same offset, and there are hundreds of them. This is not a find-and-replace problem: the numbers all differ, and minutes and seconds roll over at 60 rather than 100, so arithmetic done by hand goes wrong at every boundary.

If the gap grows as the video goes on, an offset will not fix it at all. That is a frame rate mismatch and it needs stretching rather than shifting. Which of the two you have is worth establishing before you touch anything, and the way to tell is to check the sync at the start, the middle and the end.

Both are covered in the guide on out-of-sync subtitles. The short version is that the fix belongs in something that understands timecodes, and that a text editor is the right tool for words and the wrong one for timing.

Editing it here instead

Drop the video in and import the .srt, and the lines appear as an editable list beside a waveform, with the caption drawn on the video as it plays. That is the part a text editor cannot give you: you are reading each line against the moment it covers rather than imagining it.

The editor also flags what is mechanically checkable. Lines running faster than 17 characters a second, lines shorter than 0.8333333333333334 seconds, cues that overlap each other, and lines past 42 characters or 2 rows. None of those are style opinions. They are the cases where a viewer physically cannot finish reading before the caption goes.

When you are done, export the .srt again, export it as .vtt for the web, or burn it into the picture for a feed that takes no sidecar file.

When editing is the wrong answer

If you are correcting more than every few lines, you are doing the model's job by hand. Re-transcribing with the larger model and fixing the handful of remaining errors is usually faster than repairing a bad transcript line by line, and the result is more consistent, because the mistakes you had not noticed get fixed too.

The exception is proper nouns. No model size reliably gets an unusual surname or a product name right, so those stay a manual pass whatever you do. Search for them specifically rather than reading top to bottom.