What the SRT Subtitle Validator does
This validator reads an SRT subtitle file and lists every structural problem with the line it is on: cue numbers that skip or repeat, timecodes a strict player will refuse, cues that overlap or run backwards, zero-length cues, missing blank lines between cues, empty cues and encoding damage. It then writes a repaired copy you can download as SRT or WebVTT.
SRT looks forgiving because most desktop players shrug off small mistakes. Broadcast ingest systems, streaming platforms and some smart-TV players do not, and a single comma typed as a full stop can make a whole file fail QC. Everything here runs in your browser; the file is never uploaded.
How to use it
- Paste the SRT text, or drop the file onto the box. Loading the file is better than pasting: it lets the page check the raw bytes for a byte-order mark, UTF-16 and invalid UTF-8, which a paste hides.
- Press Validate. Errors, warnings and notes appear in line order, each with the line number to jump to in your editor.
- Read the timing overview to see every cue's start, end and duration, and sort it to find the shortest or longest cues.
- Open Repair options if you need a minimum gap between cues or Unix line endings, then copy or download the repaired SRT or a WebVTT version.
- Check the list of repair changes before you ship the file. The repair never rewrites dialogue; anything it cannot fix safely is listed for you to resolve.
Reading the results
Errors stop a strict player or ingest check: a timecode that cannot be read, a cue with no text, a cue that ends before it starts, cues out of order, or two cues run together without a blank line.
Warnings usually play but are worth fixing: numbering gaps, overlapping cues, timecodes with a full stop instead of a comma, bare carriage returns and double-encoded characters such as é for é.
Notes are informational: a UTF-8 byte-order mark, trailing spaces, position text after the end time, or tags other than <i>, <b>, <u> and <font>, which many players print literally.
Worked example: a seven-cue file exported from a hand-edited transcript
Load the "SRT with problems" example. Findings count cues by their position in the file, which is what matters once the numbering is wrong. The second cue starts at 00:00:03,500 but the first ends at 00:00:03,800, so they overlap by 300 ms. The third cue is numbered 4 where 3 was expected, and its start time uses a full stop (00:00:06.100) - fine for WebVTT, not for strict SRT.
The fourth cue starts and ends at 00:00:09,000 and has no text, so it is an error twice over. The sixth begins at 10 seconds, before the fifth at 12 seconds, and follows it without a blank line. The seventh ends at 13 seconds but starts at 15, and its text contains "Café" - the tell-tale sign of UTF-8 read as Windows-1252. That is 5 errors and 4 warnings across 7 cues.
The repair drops the empty cue, swaps the reversed times, sorts the cues into time order, trims the first cue to end at 00:00:03,500 and the ferry cue to end at 00:00:13,000 so nothing overlaps, rewrites every timecode as HH:MM:SS,mmm and renumbers from 1, leaving six cues. It deliberately leaves "Café" alone: guessing at text is not a repair, so fix the encoding at the source.
What a valid SRT file looks like
SubRip has no formal standard, but the de facto format is simple: a cue number on its own line, a timing line such as 00:01:02,500 --> 00:01:05,000, one or more lines of text, and a blank line before the next cue. Hours, minutes and seconds are two digits each, milliseconds three, separated by a comma.
WebVTT, the web's caption format, is close but different: it starts with a WEBVTT header, uses a full stop before the milliseconds, allows the hours to be omitted and makes cue identifiers optional. This page recognises both, applies the right timecode rule to each and can convert a repaired SRT to WebVTT.
Why encoding problems are the hardest to spot
An SRT saved as Windows-1252 and read as UTF-8 turns accented letters into the replacement character �. The reverse mistake - UTF-8 read as Windows-1252 and saved again - turns é into é. Both look like typos in a text editor, but no amount of retyping fixes the rest of the file. Loading the file here decodes the raw bytes strictly, so invalid UTF-8 is reported even if the text looks almost right.
Limitations: what the result does not prove
- It checks structure and timing, not language. Spelling, translation quality and whether a subtitle matches the audio are outside what a file check can see.
- Reading speed, characters per line and minimum duration belong to a style guide rather than to the file format; use the Subtitle Reading Speed Checker for those.
- Double-encoding detection looks for the common UTF-8-as-Windows-1252 patterns. Other mix-ups, such as Cyrillic saved in the wrong code page, may not be recognised.
- Overlap repair shortens the earlier cue. If two cues genuinely need to be on screen together, as some broadcast formats allow, resolve them by hand instead.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- W3C - WebVTT: The Web Video Text Tracks Format
- WHATWG Encoding Standard - UTF-8 decode and BOM handling
- Netflix Timed Text Style Guide - general requirements
Frequently asked questions
Why does my SRT work in VLC but fail on a streaming platform?
Desktop players are lenient: they accept full stops in timecodes, missing numbers and overlapping cues. Platform ingest tools usually parse strictly and reject the file at the first malformed timecode or out-of-order cue. Fix every error and warning listed here and most rejections disappear.
Is a comma or a full stop correct before the milliseconds?
SRT uses a comma, as in 00:00:01,500. WebVTT uses a full stop, as in 00:00:01.500. Many SRT players accept either, which is why the full stop is a warning rather than an error here, but strict tools and some TVs do not.
Should an SRT file have a byte-order mark?
It is optional. A UTF-8 byte-order mark helps some Windows software recognise the encoding, while a few older players display it as a stray character before the first subtitle. If you do not know what your target expects, UTF-8 without a BOM is the safer default.
Do SRT cue numbers have to start at 1 and go up by one?
Most players ignore the numbers and go by the timecodes, but many validators and editing tools expect 1, 2, 3 and so on. The repaired file is always renumbered from 1 in time order, so a gap or duplicate never survives the repair.
How does the repair decide where an overlapping cue should end?
It moves the earlier cue's end to the next cue's start, minus the minimum gap you set. If that would leave the cue with no duration because both start together, it leaves both alone and lists them, because merging or retiming them means a judgement about the dialogue.
Can I convert SRT to WebVTT here?
Yes. After validation, Download .vtt writes the repaired cues with a WEBVTT header and full-stop timecodes. Styling and positioning are not invented: SRT has no reliable equivalent, so you add WebVTT cue settings yourself if you need them.
Last reviewed by the A2Z.Tools team against the sources listed above.
