The same cue list written with a UTF-8 BOM, without one, in UTF-16, with CRLF and with bare LF, plus non-Latin scripts and right-to-left text — for finding the parser that assumed captions are always LF-terminated ASCII.
Plain UTF-8, no byte-order mark, Unix LF line endings. The reference member of this set — every other file here carries the same five cues, so a parser's output can be diffed against this one. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
UTF-8 with a leading U+FEFF byte-order mark. Windows caption tools emit this constantly, and a parser that does not strip it sees the BOM as part of the first cue number and fails to match its index. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
UTF-8 with Windows CRLF line endings. Parsers that split on a bare \n leave a trailing carriage return on every line, which usually surfaces as a stray box glyph at the end of each caption. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
Both awkward properties at once — a BOM and CRLF endings — which is what a file saved by Notepad on Windows actually looks like. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
UTF-16 little-endian with a BOM. Every second byte is NUL, so a parser that reads bytes as UTF-8 or ASCII sees a file that appears to start and end immediately. Tools must detect the BOM, not assume UTF-8. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
UTF-16 big-endian with a BOM — the byte order most decoders forget to handle, since little-endian dominates in practice. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
Japanese captions mixing kana, kanji and full-width punctuation. Full-width characters occupy two columns in a monospaced renderer, so line-length limits computed in code points under-count them.
Right-to-left Arabic with joined letterforms, including a bidirectional line where Western digits sit inside RTL text. Exercises the bidi algorithm and any renderer that assumes left-to-right layout.
Right-to-left Hebrew without letter joining — a second RTL script, so a renderer cannot pass by special-casing Arabic shaping alone.
Cyrillic captions — outside ASCII but still single-width and left-to-right, which isolates encoding handling from layout handling.
Characters above the Basic Multilingual Plane, a composed/decomposed accent pair, and a zero-width-joiner sequence. Anything that measures caption length in UTF-16 code units rather than graphemes miscounts these.
Broadcast closed captions as Scenarist SCC: SMPTE timecodes followed by hexadecimal CEA-608 byte pairs, with odd parity set on every byte as the standard requires. Uses pop-on mode — RCL to load, ENM to clear non-displayed memory, a preamble address code for row 15, the character pairs, then EOC to display. This is the fixture that exposes decoders which treat captions as text: the parity bits, the two-byte control codes and the frame-accurate timecodes all have to be handled.
WebVTT cues carrying the full positioning grammar — line, position, align and size — plus named cue identifiers instead of numbers. Captions are placed at four different points in the frame, which is what real subtitles do to avoid covering burned-in text. Parsers that treat everything after the timestamp as cue text will fold these settings into the visible caption.
WebVTT exercising the parts of the format beyond plain text: a STYLE block with ::cue selectors, a named REGION, voice spans, cue classes, and inline bold/italic/underline/ruby markup. A parser that handles only timestamps and text will render the tag names as visible characters.
The same cues in Windows-1252, the legacy code page behind most real-world caption mojibake. Pure ASCII until the curly quotes and em dash, which encode as single bytes 0x93, 0x94 and 0x97 — none of which is valid UTF-8. A tool that assumes UTF-8 either raises or silently substitutes replacement characters exactly where the punctuation was. There is no BOM and no in-band signal, so correct handling requires either charset detection or being told.
Identical to the reference file except the final newline is missing, so the last cue is terminated by end-of-file rather than by a blank line. SubRip separates cues with a blank line, and parsers that split on a double newline and discard the remainder drop the final cue entirely — a bug that is invisible until a file happens to end this way.
One file with both line-ending conventions — CRLF for the opening cues and bare LF for the rest, the shape a caption file takes after being edited on two platforms or assembled from two sources. Parsers that detect the convention once from the first line and then apply it to the whole file mis-split everything after the switch.
WebVTT with a byte-order mark ahead of the mandatory WEBVTT signature. The spec explicitly allows this, and browsers accept it — but a naive check that the file literally starts with the six bytes 'WEBVTT' rejects a perfectly valid file. The mirror image of the missing-header corrupt fixture: one is valid and often refused, the other is invalid and often accepted.
We use Google Analytics and show ads via Adsterra and Infolinks. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
