Novus Examples, Real, documented example files for testing

sRGB Colour-Space Note PNG

PNG whose colour intent is documented as sRGB in specs (no mandatory ICC blob), for tools that read metadata/specs.

File: PNG · EXIF Icc · 288 × 288 px
Use case: ICC / colour profile· Conversion set

SRT, Intentionally Corrupt: End Before Start

An intentionally corrupt SubRip file whose first cue ends three seconds before it begins. Nothing is malformed at the text level, so parsers accept it and the problem only surfaces downstream, as a negative duration, a caption that never displays, or a sort that puts the timeline out of order.

File: SRT · Captions Corrupt
Use case: Subtitle parsingVideo QA· Conversion set

SRT, Intentionally Corrupt: Invalid UTF-8 Byte Sequence

An intentionally corrupt SubRip file with a lone UTF-8 continuation byte appended: a byte that can never legally start a character. Both cues are otherwise fine. Exercises the difference between strict decoding, which raises, and lenient decoding, which substitutes a replacement character and continues.

File: SRT · Captions Corrupt · UTF-8 with one invalid sequence
Use case: Subtitle parsingVideo QA· Conversion set

SRT, Intentionally Corrupt: Missing Timestamp Arrow

An intentionally corrupt SubRip file: the first cue's timing line is missing the --> separator, so it cannot be parsed as a time range. The second cue is well-formed, which is the point: a robust parser should report the bad cue and still return the good one rather than failing the whole file.

File: SRT · Captions Corrupt
Use case: Subtitle parsingVideo QA· Conversion set

SRT, Intentionally Corrupt: Non-Numeric Cue Index

An intentionally corrupt SubRip file with two separate index problems: the first cue is numbered with a word, and index 2 is then used twice. SubRip indices are advisory rather than load-bearing, so this distinguishes parsers that key cues by index (and lose one to the collision) from those that do not.

File: SRT · Captions Corrupt · 3 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT, Intentionally Corrupt: Truncated Mid-Cue

An intentionally corrupt SubRip file that stops in the middle of the third cue's timestamp, as a truncated download or an interrupted write would. There is no trailing newline. Tests whether a parser returns the two complete cues or discards everything because the tail is unparseable.

File: SRT · Captions Corrupt
Use case: Subtitle parsingVideo QA· Conversion set

SRT: 500-Cue Throughput File

Five hundred short sequential cues over four minutes. Small in bytes but long enough to expose quadratic parsing, per-cue DOM churn, and UI that re-renders the whole caption list on every cue change.

File: SRT · Captions Edge · 500 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT: CJK (Japanese)

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.

File: SRT · Captions Encoding · 3 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT: Cue Text Containing the Timestamp Arrow

Cue text that contains the --> separator, and a second cue whose text looks exactly like a timing line. A parser that finds timing lines by searching for '-->' anywhere rather than by tracking cue structure splits these into extra phantom cues. Structurally valid SubRip throughout: the file is correct and the naive parser is wrong.

File: SRT · Captions Edge · 3 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT: Cues Out of Chronological Order

Cue indices run 1, 2, 3 but the timestamps do not: the file is ordered 6.5s, 1.0s, 3.5s. The spec does not require chronological order, so a conforming parser must sort by start time rather than trusting file order. Parsers that stream cues straight to a renderer show them in the wrong sequence.

File: SRT · Captions Edge · 3 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT: Cyrillic

Cyrillic captions: outside ASCII but still single-width and left-to-right, which isolates encoding handling from layout handling.

File: SRT · Captions Encoding · 2 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT: Emoji and combining marks

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.

File: SRT · Captions Encoding · 3 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT: HTML Entities and Angle Brackets in Cue Text

Cue text mixing escaped entities, raw ampersands, unescaped angle brackets used as maths, and one genuine italic tag. SubRip has no formal escaping rules, so every parser draws the line somewhere different. Shows immediately whether a tool decodes entities, passes them through, or mistakes '3 < 5' for an unclosed tag and swallows the rest of the line.

File: SRT · Captions Edge · 4 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT: Mixed CRLF and LF Line Endings

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.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT: No Trailing Newline

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.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT: Over-Long Caption Line

One caption line of 334 characters against a 32-column broadcast convention. Exercises wrapping, truncation and validation paths, and shows immediately whether a burn-in tool wraps text or lets it run off the frame.

File: SRT · Captions Edge · 2 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT: Overlapping Cues

Three cues whose time ranges deliberately overlap, so at 3.2 seconds all three are active at once. Legal in SubRip and common in multi-speaker transcripts, but plenty of renderers assume one cue at a time and either drop the extras or stack them off-screen.

File: SRT · Captions Edge · 3 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT: RTL (Arabic)

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.

File: SRT · Captions Encoding · 3 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT: RTL (Hebrew)

Right-to-left Hebrew without letter joining: a second RTL script, so a renderer cannot pass by special-casing Arabic shaping alone.

File: SRT · Captions Encoding · 2 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT: Soft-Sub Companion

Companion SRT for the soft-sub MP4: same SAMPLE cue timings.

File: SRT · Subs
Use case: Subtitle parsingConversion testing· Conversion set

SRT: Speaker Labels and Dialogue Dashes

The conventions captioners actually use: speaker names in caps, leading dashes for alternating dialogue, square brackets and parentheses for sound effects, and music notes around lyrics. None is part of the SubRip grammar, so tools that extract speaker names or strip non-speech cues have to pattern-match them. Useful for testing transcript extraction and caption-cleaning passes.

File: SRT · Captions Edge · 5 cues
Use case: Subtitle parsingVideo QA· Conversion set

SRT: UTF-16 BE with BOM

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.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT: UTF-16 LE with BOM

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.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

SRT: UTF-8 with BOM, CRLF

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.

File: SRT · Captions Encoding · 5 cues
Use case: Caption encodingSubtitle parsing+1· Conversion set

Explore the test library

Filter the library

5297 results