SRT File Not Working? 9 Causes and How to Fix Each

Short answer: most broken SRTs fail for one of three reasons: the file name or location doesn't match the video (so the player never loads it), the timing lines aren't in exact 00:00:00,000 --> 00:00:00,000 form, or the file isn't saved as UTF-8. Paste the file into the free Subtitle Validator to see which line is wrong. Then repair overlaps, reading speed and line length with Fix Subtitles.

Below are the nine causes in the order we'd check them, each with the symptom, how to confirm it in under a minute, and the fix.

Step 0: open the file in a plain-text editor

Before anything else, open the .srt in a plain-text editor such as Notepad, TextEdit (in plain-text mode) or VS Code, not Word. A healthy file starts like this:

1
00:00:01,000 --> 00:00:03,200
First line of dialogue.

2
00:00:03,400 --> 00:00:05,900
Second line.

If the file opens as one long line, contains {\rtf, or starts with WEBVTT, you've found your problem already. It's either not plain text or not an SRT at all.

Diagnose by symptom

1. The player never loads the file

Symptom: nothing appears and no error shows.

Check: VLC and most TVs only pick up a sidecar automatically when it sits in the same folder with the same base name: Trip.mp4 and Trip.srt, not Trip.mp4.srt or trip-final.srt.

Fix: rename the file, or load it by hand. In VLC, use Subtitle → Add Subtitle File. On a TV, check that its USB player supports external SRT for that container. Some don't support it for MKV or MP4 at all. In that case, burn the subtitles into the picture with Burn Subtitles.

2. The timecode line is malformed

Symptom: "invalid subtitle file," zero cues imported, or cues missing from one point onward.

SRT is strict about the timing line. Every one of these fails in at least some players or editors:

00:00:04.200 --> 00:00:06,000   ← period instead of comma
0:00:04,200 --> 0:00:06,000     ← one-digit hours
00:00:04,2 --> 00:00:06,000     ← milliseconds not 3 digits
00:00:04,200 -> 00:00:06,000    ← arrow has one dash
00:00:04,200-->00:00:06,000     ← no spaces around the arrow

The correct form is HH:MM:SS,mmm --> HH:MM:SS,mmm. Periods are correct in WebVTT, which is why a VTT renamed to .srt breaks. Convert it properly with VTT to SRT instead.

Fix: the Validator flags a timing line that isn't in SRT format. On our test file it didn't say which cue, though, so search the timing lines for a period yourself. Fix Subtitles rewrote our 00:00:04.200 as 00:00:04,200. For a whole file with periods, a find-and-replace on the timing lines only (never the text) works, but converting is safer.

3. Numbering or blank lines are broken

Symptom: cues merge, text appears in the wrong cue, or import stops partway.

Look for a duplicated index (two cue 5s), a text line that starts with a number (a parser can read 3 people came as an index), or a missing blank line between cues. Hand-edited and merged files are the usual source.

Fix: renumber and restore blank lines. The Validator catches a duplicate index, but only in general terms: on our test file it said "1 cue number is missing, repeated or out of sequence" without naming the cue. Fix Subtitles renumbers the whole file in order. If you combined two files, re-merge them with Merge SRT Files so the numbering and order are rebuilt.

4. Invisible characters before the first cue

Symptom: the first cue is missing or shows "1" as text, while everything else works.

Some editors save UTF-8 with a byte-order mark (BOM). Most players ignore it, but some strict parsers read the BOM as part of the first index. Copy-pasting from web pages can also add non-breaking spaces.

Fix: re-save as "UTF-8" (without BOM) in VS Code or Notepad++. Or delete the first line and retype 1.

5. Accents and non-Latin text show as garbage

Symptom: café instead of café, or ?/� in place of characters.

The file was saved in a legacy encoding such as Windows-1252, and the player read it as UTF-8, or the other way round. WebVTT is required to be UTF-8 (W3C WebVTT). SRT has no declared encoding, so players guess.

Fix: open the file in an editor that lets you reopen with encoding, choose the original encoding until the text reads correctly, then save as UTF-8. Don't "fix" mojibake by retyping. You'll miss some.

What happened in our test. Our Windows-1252 test SRT had café, Señora Peña, a curly apostrophe and an em dash. The Subtitle Validator didn't mention the encoding. Fix Subtitles saved its output as UTF-8 with é and ñ correct, but the curly apostrophe and em dash came out as invisible control characters. So convert a legacy-encoded file to UTF-8 yourself first, then run the repair.

6. Cues overlap

Symptom: two subtitles stack on screen, captions flicker, or a platform warns about overlapping cues.

4
00:00:03,900 --> 00:00:07,400
I uploaded the interview, and the subtitles were ready.

5
00:00:07,200 --> 00:00:08,650
Did you have to fix anything?

Cue 4 ends 0.2 s after cue 5 starts. Overlaps usually come from merging files, manual re-timing, or translation tools that stretch out-times.

Fix: Fix Subtitles separates overlapping cues so only one shows at a time. Professional specs also want a small gap: Netflix requires at least 2 frames between subtitles (timing guidelines). More on this case: fix overlapping subtitles.

7. Everything is early or late by the same amount

Symptom: every line is, say, 1.5 s late from start to finish.

Common causes: the video was trimmed at the head after the subtitles were made, or a title card or ident was added.

Fix: Shift Subtitle Timing moves the whole file forward or backward. Enter the offset as a number of seconds (1.5 for the example above) and set the Forward/Backward toggle. It shifts every cue by the same amount. There's no way to shift only part of the file. Measure the offset on the first line of dialogue, apply it, then check a line near the end. If the end is still off, it's not an offset (see 8). In an editor like DaVinci Resolve, a one-hour offset usually means the timeline starts at 01:00:00:00, so enter 3600 and shift forward. See importing SRT into DaVinci Resolve.

8. Sync gets worse over time (drift)

Symptom: fine at the start, a second off by the middle, several seconds off by the end.

This is almost always a frame-rate or speed mismatch. Subtitles timed against 25 fps playback but shown on a 23.976 fps version drift by about 4% (25 ÷ 23.976 ≈ 1.043), which is roughly 2.5 s every minute. It can also mean the subtitles belong to a different cut with scenes added or removed.

Fix: a constant shift won't help. Either re-time by a ratio (stretch) in a desktop subtitle editor, or regenerate subtitles from the exact video you're publishing with Video to Subtitles. If it's a different cut, regenerating is the reliable option. Full walkthrough: fixing subtitle timing drift.

9. It imports, but it's rejected or flagged

Symptom: the platform or client QC bounces the file even though it plays.

Here the file is valid but breaks readability rules:

Fix Subtitles' defaults line up with the Netflix English numbers but aren't a Netflix, BBC or EBU certification. Treat its report as QC, not sign-off. If your spec is 37 characters or a 7-second cap, re-check with the character checker and reading speed checker.

How Fix Subtitles works (and what it won't do)

1. Upload SRT or VTT, up to 20 MB. Checking is free.
2. See what's wrong: overlaps, reading speed, cue length and line length, counted and listed.
3. Fix: choose what to repair. Fixing needs a free account. Optional grammar and filler-word cleanup changes wording, so it's off unless you turn it on.
4. Download the fixed file, plus a list of anything that still needs a person, with where it is.

Add the source video and it also flags cues that cross a camera cut. Your original file is never changed.

Our test run. We built a broken 12-cue SRT with an overlap, a duplicate cue number, a period timecode, a 107-character line and Windows-1252 encoding planted in it. The Validator summed it up as "12 cues checked, 2 errors, 3 warnings" and offered "Fix 3 safe problems". Here's what each tool did:

Cue 2 already has all the time it can get, so a person has to shorten the wording.

When to stop fixing and regenerate

Repairing beats regenerating when the words are right and the problems are mechanical. Regenerate when:

• the subtitles belong to a different edit,
• more than a handful of cues are in the wrong language or garbled, or
• drift comes from an unknown frame-rate conversion.

Our MP4 to SRT guide covers generating a clean file from the final export. If the file is a translation that now breaks reading speed, see translating SRT to Spanish. Translated lines often run longer.