Four Kinds of Dirty Data in SRT: Symptoms and Fixes
After subtitles pass back and forth between editing software, translation tools and platforms, "dirty data" accumulates quietly. It isn't always visible, but it makes players skip cues and platform uploads error out. Learn to recognize the four common problems, then decide how to clean.
Especially in cross-border workflows — cut in an editor, translated on one platform, uploaded on another — the file passes through many hands, so dirty data piles up far more than in a single-stage pipeline.
Type one: timeline overlap
Two cues' time ranges cross — the previous one hasn't ended before the next starts.
00:00:01,000 --> 00:00:03,000
第一句
00:00:02,500 --> 00:00:04,500
第二句
Usually caused by hand-editing timecodes wrong, or automatic recognition slicing adjacent boundaries incorrectly. On overlap, a player may show only one cue or flash between both. The fix is re-squaring the boundaries so adjacent cues meet end-to-start. Recognition-generated subtitles hit this most — models don't split sentences as cleanly as humans do.
Type two: duplicate lines
The same text appears twice, or adjacent cues are identical. Often from copy-paste or merging segments without dedupe. The fix is deleting the duplicate and correcting the timeline afterward.
The other annoyance: duplicates inflate the cue count, so per-cue-billed steps (some platforms' review or translation) overcharge. Removing duplicates is both a look fix and a cost fix.
Type three: index chaos
Cue indexes skip, jump or repeat. SRT is actually lenient here — most players order by timeline, not index. But some platforms validate index continuity on upload and reject the file outright. Fix: renumber 1, 2, 3… in appearance order.
Type four: leftover tags
Text carrying HTML-style tags like <i>, <font color>, <b>. They come from certain editors or translation tools; SRT should never have them. Symptoms: rendered as odd characters as-is, or the whole cue errors out under strict parsing. Fix: strip the tags, keep plain text.
Leftover tags come from all over: forgetting "plain text" when exporting from a styled editor, translation tools carrying source styling along, or manual emphasis marks added inside cues. The sneakiest part: the subtitle reads fine by eye while invisible markers hide in the file, surfacing only when some platform finally rejects it.
Which ones make platforms fail outright
Index discontinuity — some platforms hard-validate and reject immediately; invalid format (missing arrow in the timecode, wrong millisecond digits) — parsing fails; leftover tags under strict mode — the whole cue may be dropped.
Overlaps and duplicates usually aren't fatal but drag down the look. Even when the platform doesn't complain, they show — cleaning before delivery never hurts. Suggested self-check order: index continuity first, format validity second, leftover tags last. Any of the three failing can sink an otherwise-finished upload, and cleanup-plus-check catches essentially all of them.
How to clean
Take SmileSub's subtitle cleaner — no login: upload the SRT, the tool scans overlaps, duplicates, indexes and leftover tags, download the cleaned file.
Free tier: 1MB and 500 cues per file, 3 uses per tool per IP per day. After cleaning, re-verify with the subtitle checker for extra safety.
Cleaning is insurance before destructive steps — export a backup of the original first, then clean, so you can roll back if anything goes wrong.
If the subtitles are headed for translation, clean before translating — otherwise tags ride into the translation and pollute the output. For that flow, see SRT translation to English.
FAQ
Do wrong indexes affect playback?
Most players sort by timeline, so no. But some platforms validate index continuity on upload and reject mismatches — straighten the indexes before delivery.
What happens if leftover tags stay?
Best case, they render as odd characters; worst case, strict parsing drops the whole cue. SRT doesn't support style tags at all — stripping is the safe move.
Does cleaning change my translation?
No. Cleaning touches structure-level issues only (overlaps, duplicates, indexes, tags); the text stays as-is. Translation content is unaffected.