Wrong timestamp syntax
SRT commonly uses HH:MM:SS,mmm. Dot-style WebVTT timestamps belong to VTT, so a renamed or mixed-format file may confuse a strict importer.
When an editor or player rejects an SRT, the problem is often structural rather than the subtitle wording. Use this checklist to find the mechanical issue before trying to re-export the file.
It checks the same families of problems described below and can preview safe structural repairs.
SRT commonly uses HH:MM:SS,mmm. Dot-style WebVTT timestamps belong to VTT, so a renamed or mixed-format file may confuse a strict importer.
Each SRT cue normally has a number, timing line, subtitle text and a blank line before the next cue. A missing separator can merge cues together.
Unexpected, duplicated or malformed cue numbers can cause import issues in stricter applications. Sequential numbering is easy to normalize.
A cue cannot reliably display when its end time is equal to or earlier than its start. These are structural errors, not wording problems.
Undecodable text or replacement characters can make subtitles display incorrectly or cause a workflow to reject the file. Check encoding before delivery.
Web players often expect WebVTT, while many desktop subtitle workflows use SRT. Do not solve a format mismatch just by renaming the file extension.
Check that the file is really SRT, timestamps use the expected comma format, cues are separated correctly, numbers are valid, and timing is not reversed. Then inspect overlaps and unsupported markup if the file imports but displays strangely.
Check the format first. WebVTT requires the WEBVTT header and uses a dot before milliseconds. Also check backwards timing and undecodable characters.
That is often a readability or timing issue rather than a parser failure. Inspect overlaps, CPS, line length, number of lines and cue duration.
Use the checker to identify exact cue-level findings and download a plain-text report you can keep with the subtitle delivery.