Deliberately corrupt and invalid files, clearly labelled, for testing how your tool fails.
An intentionally corrupt JPEG, truncated to half its bytes, for testing how a decoder handles incomplete image data. This is not a valid image by design.
A 440 Hz tone driven past full scale and hard-clipped so its peaks are flat-topped — an intentionally clipped signal for testing clip and true-peak detection, distortion metering, and de-clipping tools.
A clean 440 Hz tone interrupted by a short high-amplitude click at 0.4s — for click/pop removal tools.
An intentionally corrupt PDF, truncated to 60% of its bytes, for testing how a PDF parser handles a damaged file. Not a valid document by design.
An encrypted PDF protected with the openly-published sample password “novus-sample” — printing is allowed, editing denied. A fixture for testing password-prompt handling, decryption, and permission flags. There is nothing secret inside.
A deliberately messy CSV: a quoted field with a comma, a quoted field with an embedded newline, escaped double-quotes, and ragged rows with too few and too many fields — the cases that break naïve parsers.
An intentionally invalid JSON file with a trailing comma and a missing closing brace — for testing parser error handling and messages. Not valid JSON by design.
A product object that deliberately violates the product JSON Schema in five ways (out-of-range id, empty name, non-positive price, wrong boolean type, an extra property) — the negative case for testing validator error reporting.
A realistic Java stack trace — a Spring-style NullPointerException with a nested 'Caused by' chain and '... N more' elision. A fixture for testing stack-trace parsers, error groupers, and log viewers.
A realistic Python traceback with a chained exception ('During handling of the above exception...') and a caret error indicator. A fixture for testing traceback parsers and error-reporting tools.
A realistic Node.js/Express stack trace — a TypeError with V8-style 'at function (file:line:col)' frames including an async frame and internal node: frames. A fixture for testing JS stack-trace parsers.
A CSV where missing values are written seven different ways — empty string, NULL, NA, N/A, null, None, and a dash — across text and numeric columns. A fixture for testing null-detection and coercion in CSV importers.
A CSV whose 'value' column mixes integers, floats, scientific notation, dates, hex, thousands separators, and whitespace, and whose 'flag' column mixes a dozen boolean spellings. A torture test for type inference and schema detection.
A JSON object that repeats several member names (name, tags, timeout, active). RFC 8259 permits duplicate keys but leaves the result parser-defined — most keep the last. A fixture for testing how a JSON parser resolves duplicates.
A CSV listing timestamps in eleven formats — ISO 8601 with Z and numeric offsets, millisecond precision, naive local, date-only, Unix epoch in seconds and milliseconds, US AM/PM, and RFC 1123. A fixture for testing date parsing and timezone normalisation.
A small CSV whose header row repeats the column name id — a common importer failure mode.
A sanitization-test CSV with one equals-prefixed cell clearly labelled sample-only. Use it to verify importers neutralize spreadsheet formulas — not an attack list.
A .csv file whose content is tab-delimited — tests whether importers sniff delimiters or trust the extension.
A CSV with a quoted field that contains an embedded newline — a classic RFC 4180 parser stress case.
Rows with differing field counts — for testing how importers pad, truncate, or error on ragged CSV.
OpenAPI document with paths set to null — intentionally invalid for negative schema tests.
OpenAPI with a response schema $ref pointing at a missing component — tests broken-reference detection.
OpenAPI with an unsupported openapi version string — negative case for version validators.
User JSON deliberately violating the schema five ways — negative case for validator error reporting.
Two rows share the same timestamp key — tests deduplication and last-write-wins policies.
GraphQL error response with message and location — negative case for GraphQL clients.
Intentionally invalid JSON Schema (json-schema-missing-type) for negative validator tests.
Intentionally invalid JSON Schema (json-schema-bad-ref) for negative validator tests.
Intentionally invalid JSON Schema (json-schema-empty-object) for negative validator tests.
Invalid payment JSON (negative amount, short currency) for schema error reporting tests.
RFC 7807 SAMPLE problem document for HTTP 404 (Not Found) client tests.
RFC 7807 SAMPLE problem document for HTTP 401 (Unauthorized) client tests.
RFC 7807 SAMPLE problem document for HTTP 403 (Forbidden) client tests.
RFC 7807 SAMPLE problem document for HTTP 409 (Conflict) client tests.
RFC 7807 SAMPLE problem document for HTTP 410 (Gone) client tests.
RFC 7807 SAMPLE problem document for HTTP 429 (Too Many Requests) client tests.
RFC 7807 SAMPLE problem document for HTTP 422 (Unprocessable Entity) client tests.
RFC 7807 SAMPLE problem document for HTTP 400 (Bad Request) client tests.
RFC 7807 SAMPLE problem document for HTTP 415 (Unsupported Media Type) client tests.
RFC 7807 SAMPLE problem document for HTTP 406 (Not Acceptable) client tests.
RFC 7807 SAMPLE problem document for HTTP 503 (Service Unavailable) client tests.
RFC 7807 SAMPLE problem document for HTTP 500 (Internal Server Error) client tests.
Tiny SAMPLE CSV (semicolon-eu) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (pipe-delimited) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (hash-commented) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (quoted-embedded-comma) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (quoted-embedded-newline) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (empty-fields) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (trailing-comma) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (header-only) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (single-column) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE CSV (mixed-quoting) exercising delimiter/quoting edge behaviour.
Tiny SAMPLE log excerpt (nginx-access-sample) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (nginx-error-sample) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (app-json-structured) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (systemd-journal-excerpt) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (multiline-stacktrace) for parser and alert-rule tests.
Tiny SAMPLE log excerpt (cloudflare-ray-sample) for parser and alert-rule tests.
A ZIP written the way a streaming writer must write one: general-purpose bit 3 is set, the local header carries CRC 0 and sizes 0, and the real values follow the compressed data in a data descriptor introduced by the optional PK\x07\x08 signature.
The same streaming layout with the data descriptor's PK\x07\x08 signature omitted, which the spec permits and which breaks readers that scan for the signature instead of trusting the central directory. The central directory here carries the authoritative sizes and CRCs.
A streaming ZIP in ZIP64 form: the data descriptor's compressed and uncompressed sizes are 8 bytes each rather than 4. Readers that assume a fixed 16-byte descriptor desynchronise on the very next local header.
Directory records whose names do NOT end in a slash — the directory-ness is carried only by the MS-DOS attribute bit in the external attributes field. A reader that decides by name alone creates three empty files called project, project/src and project/data, and then cannot create the directories that have to replace them.
Three members under docs/ whose names differ only in letter case. On ext4 they are three files; on NTFS or a default APFS volume they are one file written three times, and the last one silently wins. Each payload names its own casing so you can tell which survived.
Two members use a backslash as the path separator, which APPNOTE 4.4.17.1 forbids and which Windows-written archives contain anyway. Readers that split on '/' only will create files literally named 'data\config.json' in the extraction root instead of data/config.json.
Member names carrying './' prefixes, an inner './' and one inner '../' that cancels the segment before it. Every path resolves inside the archive root, so this exercises a normaliser without being a traversal payload: docs/sub/../notes.md must land at docs/notes.md, not at docs/sub/notes.md and not outside the extraction directory.
Both the local file headers and the central directory carry a ZIP64 extended information extra field (0x0001), with the 32-bit size fields set to 0xFFFFFFFF as the spec requires. The payload is a few hundred bytes: ZIP64 is present because the writer could not seek, not because the data is large, which is precisely the case size-based heuristics miss.
The local headers are plain 32-bit while the central directory carries the ZIP64 extra field. This is legal and common: a writer that streams cannot know at local-header time whether it will need ZIP64, so it commits to the wide fields only when it writes the directory.
A central directory whose ZIP64 extra field carries the relative local-header offset as well as the sizes. The ZIP64 extra is variable length and its members appear in a fixed order, so a reader that assumes a 16-byte or 24-byte block reads the offset out of the wrong slot.
Ordinary 32-bit member records terminated by a ZIP64 end-of-central-directory record, its locator, and then a normal 32-bit end record — the belt-and-braces trailer some writers always emit. A reader must find the classic end record first, notice the locator in front of it, and reconcile two directories that agree.
A complete, extractable ZIP that begins with the four-byte PK00 marker a splitting writer emits when the archive fitted into a single segment after all. The marker shifts every local header four bytes forward, so a reader that assumes the first local header sits at offset 0 misparses a file it is perfectly capable of reading.
A complete ZIP prefixed with the 0x08074B50 spanning signature. That value is also the data descriptor signature, so a reader scanning the byte stream for descriptors finds one before the first local header — a genuine ambiguity in the format, reproduced here in a file that is otherwise entirely ordinary.
The last segment of a two-part spanned set: its end record says this is disk 1, that the central directory lives on disk 1, and that 2 of the archive's 4 entries are here. The bytes are well-formed - this is not a corrupt file - but a reader given it alone must say so rather than silently reporting a 2-entry archive. The .z01 first segment is deliberately absent, because .z01 is not a format this catalog registers.
A 512-byte archive comment pushes the end-of-central-directory record well away from the end of the file. Readers that seek to the last 22 bytes and expect the end signature there fail immediately; correct readers scan backwards for it, which is what the format requires.
An extra field with header ID 0x9901, which is assigned to nothing, sits alongside a recognised extended-timestamp field in a different order in each header. The extra-field area is a length-prefixed chain, so the only correct behaviour is to skip unknown IDs by their declared length and keep walking.
397 bytes of readable text precede the first local file header, giving the layout of a self-extracting archive without shipping an executable stub. Readers that start at byte zero see garbage; readers that find the end-of-central-directory record and work backwards read all three members. Open the file in a text editor to read the prefix.
Three empty files stored three ways - stored, deflated, and deflated behind a data descriptor - beside one real member. An empty deflate stream is still two bytes on disk with CRC 0, so readers that treat compressed size 0 as 'no data' and readers that treat CRC 0 as 'not computed' both go wrong here.
A 141-character path stored the only way plain USTAR can store one: split at a slash across the header's 155-byte prefix field and its 100-byte name field. Readers that ignore the prefix field report the truncated tail and write the file to the wrong place.
A 125-character path whose long component contains no slash at all, so the USTAR prefix field cannot store it. This archive uses a preceding 'L' (GNUTYPE_LONGNAME) record whose payload is the full path. Its group siblings encode the same class of path with the other two mechanisms.
A 125-character path whose long component contains no slash at all, so the USTAR prefix field cannot store it. This archive uses a preceding 'x' extended header carrying a path= record in UTF-8. Its group siblings encode the same class of path with the other two mechanisms.
A FIFO, a character device and a block device, each a header with no data blocks and with the device numbers in the devmajor/devminor fields. Unprivileged extraction cannot create the two device nodes, so the correct behaviour is to skip them with a warning rather than to abort the whole archive or to create empty regular files in their place.
The uid and gid fields hold 7 octal digits, so they top out at 2097151. This member is owned by uid 3000000, which needs GNU base-256 encoding: the field's high bit is set and the remaining bytes are a big-endian integer. Its group sibling encodes the same ownership the other way, so a reader can be checked against both without a second variable.
The uid and gid fields hold 7 octal digits, so they top out at 2097151. This member is owned by uid 3000000, which needs PAX uid=/gid= records in an 'x' extended header, with the classic field left at its maximum. Its group sibling encodes the same ownership the other way, so a reader can be checked against both without a second variable.
A tar that ends immediately after its last member, with none of the two 512-byte zero blocks the format calls for. Plenty of writers do this and GNU tar reads it with a warning; readers that treat a missing end marker as a truncated archive reject three perfectly good members.
A complete tar with 218 bytes of plain text appended after the end-of-archive blocks. A reader must stop at those blocks; one that keeps scanning finds a block whose checksum does not verify and may report the whole archive as corrupt instead of ignoring bytes that were never part of it.
A valid ZIP with zero members whose end record still carries an archive comment - the combination that catches readers which treat 'no entries' as 'not an archive' and readers which look for the end record only in the last 22 bytes. Its group siblings are the same empty case in five other container formats.
An empty tar is not a zero-byte file - it is exactly two 512-byte blocks of zeros, the end-of-archive marker with nothing in front of it. Writers that emit nothing at all produce a file most readers reject, which is the bug this 1024-byte file exists to distinguish.
The empty tar wrapped in gzip, which is what `tar czf` produces from an empty directory. The gzip header and trailer are still there and still have to parse, so this separates 'cannot read the codec' from 'read the codec and found nothing inside'.
The empty tar under bzip2. Its payload is 1024 identical bytes, which is the run-length case bzip2's block sorter treats specially, so this doubles as the smallest sane bzip2 stream to test a decoder against.
An empty cpio archive is a single TRAILER!!! header record - a full 110-byte newc header with every numeric field zero - plus its alignment padding. Readers that look for member data before checking the name find none and must still report a valid, empty archive.
The smallest valid archive in this catalog: the 8-byte ar magic and nothing after it. ar has no trailer record, so end-of-file is the only end marker, and this is what an empty static library or an empty .deb control archive looks like on disk.
An intentionally invalid EPUB: identical to the valid twin except its OCF mimetype entry is compressed and mislabelled as application/zip — a real EPUB spec violation. For testing how readers and validators handle a malformed container. Clearly labelled; harmless content.
An intentionally invalid fixed-layout EPUB: rendition:layout says pre-paginated but no content document declares a viewport meta, so the canvas size is undefined. Intentionally invalid and clearly labelled - for testing validators and the fallback a reader picks when it has no dimensions to scale to.
A working media overlay whose package omits the required media:duration metadata entirely. Everything else is intact, so this fixture isolates one question: does the reader refuse the overlay, or fall back to measuring the audio itself?
An intentionally invalid media overlay: the second par's text src points at a fragment identifier that does not exist in the chapter. Intentionally invalid and clearly labelled - for testing whether playback skips the orphaned segment, stops dead, or throws.
An intentionally invalid EPUB whose embedded font is IDPF-obfuscated while META-INF/encryption.xml is missing, so nothing in the container says the bytes were scrambled. Intentionally invalid and clearly labelled - this is the real-world failure where a book silently renders in a substitute face.
An intentionally invalid EPUB 3 that ships only an NCX: no manifest item carries properties="nav", which EPUB 3 requires. Intentionally invalid and clearly labelled - it separates readers that fall back to the NCX from readers that refuse to open a book with no navigation document.
A book whose two navigation surfaces tell different stories: the NCX reorders the chapters, omits one, and points at a chapter9.xhtml that does not exist, while nav.xhtml is correct. For testing which surface a reader trusts and how it handles a dead NCX target.
An intentionally invalid EPUB: the content document contains MathML while its manifest item omits properties="mathml", so the package understates what a reader needs. Intentionally invalid and clearly labelled - identical to its declared twin in every other byte of markup.
The pathological spine: every itemref is marked linear="no", so the book declares no default reading order at all. For testing what a reader opens to when the sequence it was going to page through is empty.
An intentionally invalid spine that references chapter one twice, in first and second position. Intentionally invalid and clearly labelled - it exposes pagination and progress code that assumes spine positions map one-to-one onto documents.
An intentionally invalid EPUB whose spine ends with an itemref pointing at a manifest id that does not exist. Intentionally invalid and clearly labelled - the first three chapters are intact, so a reader can recover if it chooses to.
An intentionally invalid EPUB that declares chapter3.xhtml in the manifest, the spine and the contents, while the file itself is not in the ZIP. Intentionally invalid and clearly labelled - for testing the difference between a missing resource and an unreadable book.
An intentionally invalid EPUB whose second chapter is declared as text/html instead of application/xhtml+xml, making it a foreign resource in the reading order with no fallback. Intentionally invalid and clearly labelled; the bytes of that file are ordinary, valid XHTML.
An intentionally invalid EPUB where two manifest items carry the same id, so the spine's references become ambiguous and one chapter can be reached twice while another cannot be reached at all. Intentionally invalid and clearly labelled - an XML ID uniqueness violation, not a container defect.
An intentionally invalid EPUB whose META-INF/container.xml contains an empty rootfiles element, so nothing points at the package document - even though OEBPS/content.opf is present and correct. Intentionally invalid and clearly labelled; it separates readers that guess from readers that give up cleanly.
The package document is encoded as UTF-16 little-endian with a byte order mark while the content documents stay UTF-8 - a combination EPUB permits and almost nothing tests. For finding the parser that opens the OPF as UTF-8 and sees a file full of null bytes.
The package document, the navigation document and the chapter each begin with a UTF-8 byte order mark before the XML declaration. Legal, and the classic reason a strict parser reports content before the prolog on a file that looks perfectly fine in an editor.
A glTF whose single buffer is a relative URI to a sibling .bin — the layout every DCC tool writes by default, and the one that breaks the moment an asset is moved or served from a different directory. Download the .bin in this group alongside it.
The binary payload the external-buffer glTF in this group points at: tightly-packed positions, normals and indices with 4-byte alignment padding. Not viewable on its own — its bufferViews live in the JSON.
Geometry inline, texture out of line: the image is a relative URI to a sibling PNG while the buffer is embedded, which is the mixed layout that trips asset packers expecting all-or-nothing. Download the PNG in this group with it.
A structurally perfect ASCII PLY in which one vertex reads `nan nan nan` — the value an exporter writes after dividing by a zero-length vector. The header, counts and face list are all correct, so the file parses; every bounding box, centroid and normal computed from it is then poisoned.
The same NaN vertex in Wavefront OBJ, where the literal is the bare token `nan`. Normals are deliberately not written, because the three faces touching that vertex have no computable normal — which is exactly the state an importer must handle rather than serialise.
A variable font that is intentionally incomplete: the STAT table OpenType requires of every variable font has been removed, while fvar, gvar and the named instances remain. It still renders, which is exactly the problem — style linking, family grouping and instance naming quietly degrade instead of failing loudly.
The same outlines with all three vertical-metric families deliberately set to different sums — 1000, 1250 and 1400 units. The default line height a renderer produces tells you exactly which family it read, which is the fastest way to explain why one browser or one word processor lays your text out differently from the rest. Original typeface, free to use.
usWinAscent and usWinDescent are deliberately set below the real glyph bounding box, which is the classic cause of clipped accents and cut-off descenders on Windows. The head table still reports the true extents, so a validator can catch the contradiction and a renderer can be measured against it. Original typeface, free to use.
The same design squeezed onto a 128-unit em, the coarse end of what the specification allows. Coordinates quantise hard, so this is the fixture for testing scaling maths, rounding, and any code that assumes a font has enough resolution to hint. Original typeface, free to use.
The same probe-character subset with every OpenType feature stripped — what many web-font pipelines produce by default. GSUB and GPOS survive as empty shells, so a tool that merely checks whether the tables exist reports the font as fully featured while nothing ligates, kerns, or turns into small caps. Original typeface, free to use.
This whole family is drawn as overlapping strokes rather than merged outlines, and this cut sets the two flags that tell a rasteriser so: OVERLAP_SIMPLE on simple glyphs and OVERLAP_COMPOUND on composites. For testing rasterisers that need the hint to avoid seams, and tools that must preserve the flags through a round trip. Original typeface, free to use.
The clean control for the checksum pair: a small, valid font whose head.checkSumAdjustment and every table-directory checksum are correct. Diff it against its damaged twin to see exactly which four bytes a validator is complaining about. Original typeface, free to use.
An intentionally corrupt font: four bytes of head.checkSumAdjustment overwritten with 0xDEADBEEF and nothing else touched. It still renders, because browsers and operating systems do not verify the field — which is precisely why this is a useful fixture for validators, signing tools, and font-integrity checks that claim they do.
An intentionally corrupt font whose glyf table data is perfectly fine but whose recorded checksum in the table directory is wrong. The complement to the head fixture: this one catches tools that verify per-table checksums, and its glyphs still draw, so the damage is invisible without a real integrity check.
An intentionally corrupt MP4, cut off at 55% of its length in the middle of the `mdat` box — the shape of an interrupted download or a copy from a failing disk. Not a valid file by design. The interesting property is that it opens perfectly. Because the file was written with faststart the `moov` index sits before the media data, so a probe reads a complete track list and a duration within a tenth of a second of the original, and only decoding reveals that most of the samples the index points to are not there. Tools that validate by probing pass it; tools that validate by decoding do not. The seek bar will happily let you scrub past the end of the data that exists.
An intentionally corrupt MP4 with the entire `moov` box cut out and the surrounding bytes rejoined. The `ftyp` header and all of the compressed media in `mdat` are untouched. Not a valid file by design. This is the classic 'moov atom not found' failure, and in practice the most common way an MP4 dies: the index is written last, so any recording that stops without a clean finalise — a crashed encoder, a phone that ran out of battery mid-capture — ends up exactly like this. The media is all still there, which is why recovery tools can sometimes rebuild it, and this is the file to test one against. Contrast with the truncated file in this group, which has an index and no data.
An intentionally corrupt MP4 cut off half way through its `moov` box: the `ftyp` header survives, the index does not, and there is no media data at all. Not a valid file by design. Just enough for content sniffing to succeed and everything after that to fail. A `file`-style magic check reports ISO Media, a MIME sniffer says video/mp4, and then the box walk runs off the end of the buffer part way through the index. Useful for testing the gap between format detection and format validation — and for the upload path, where the two are frequently the same check. Distinct from the two other truncations in this group: the mid-mdat file has a complete index and missing media, this one has a broken index and no media, and a length-based cut deep enough to matter is the only way to tell those code paths apart.
An intentionally corrupt MP4 containing nothing at all — zero bytes, with a `.mp4` extension. Not a valid file by design. The degenerate case, and one that reaches production more often than any other: a failed upload, a `touch`ed placeholder, a copy that never started. It is worth having because so much code divides by duration, reads the first N bytes without checking N, or reports 'unsupported format' for a file that has no format to support. Note that content sniffing cannot help here — there are no magic bytes — so anything that must classify this file has only the extension to go on.
An intentionally corrupt MP4 in which 48 individual bytes inside the `mdat` payload have been inverted, leaving every box header, the index and the file length exactly as they were. Not a valid file by design. Structurally this file is perfect — it will pass any container-level validation you throw at it — and the damage is entirely in the compressed bitstream. Expect the decoder to log errors and the picture to break up and then recover at the next keyframe, which is what makes it the right fixture for testing that a transcode pipeline actually surfaces decoder errors rather than shipping a corrupted output and reporting success. The corruption sites are fixed, so the file is reproducible byte for byte.
An intentionally corrupt Matroska file cut to 60% of its length, part way through a cluster. Not a valid file by design. Matroska degrades very differently from MP4, which is the reason to have both. Its header is at the front and its clusters are independently framed, so a truncated MKV usually plays right up to the cut and then simply ends — no index to contradict, because the Cues element that would have carried it was at the end and is gone. Duration is reported as unknown or estimated, and seeking past the cut behaves differently in every player.
An intentionally corrupt WebM, VP9 in Matroska, cut to 45% of its bytes. Not a valid file by design. The browser-facing member of this group. A truncated WebM starts playing in an HTML5 <video> element and then fires an `error` event mid-stream, which is a genuinely awkward state to handle: your player has already reported success, already hidden the spinner, and already told the user the duration. Use it to check that the error path is wired to something more useful than a frozen frame.
An intentionally corrupt fixture of a different kind: the bytes are a perfectly valid Matroska file, and the extension says `.mp4`. Nothing is damaged — the file simply lies about what it is. Not a valid MP4 by design. This is what a user's 'converted' file usually turns out to be after a rename, and it separates two kinds of code cleanly. Anything that sniffs the first four bytes finds `1A 45 DF A3`, identifies EBML and plays it. Anything that dispatches on the extension hands it to an MP4 demuxer that immediately fails to find `ftyp`. Note the catalog records this entry's MIME as video/mp4, matching the extension rather than the content — deliberately, because that is precisely the mismatch being reproduced.
An encoded-word naming a charset no registry knows. The payload happens to be UTF-8, so a decoder has a choice: fall back and show readable text, or leave the raw encoded-word visible. What it must not do is raise and drop the whole header.
A zero-length text/plain alternative next to a real HTML part — the shape produced by senders that add a plain part only to satisfy spam filters. Anything preferring plain text renders a blank message unless it falls back when the chosen part is empty.
The HTML body references a Content-ID that no part in the message provides — the everyday result of a forward that dropped an attachment. A renderer should show the alt text and carry on, not emit a broken external request or fail the whole message.
An attachment with a bare Content-Disposition: attachment and no name in either header. A client has to invent a filename, and the extension it invents decides whether the saved file opens as a spreadsheet or as unknown binary.
A single header whose value is one 1,001-character token with no whitespace, making the line 1,024 octets — past the 998-octet limit RFC 5322 sets and impossible to fold. Fixed-size line buffers truncate here, and the truncation is silent.
The immediate parent named by In-Reply-To was never delivered, but its grandparent is in the References chain. A threader has to fall back up the chain instead of orphaning the message — the everyday case after a deleted or filtered message.
A References header that lists the same two Message-IDs twice, in a repeating order — what a client produces when it appends without checking. A threader that treats the chain as a literal path builds a cycle or reports a depth of four for a two-deep thread.
A multipart/report that advertises report-type=delivery-status but is deliberately incomplete: the required message/delivery-status part is missing, leaving only human prose and the returned headers. Real MTAs emit this, and a parser must not assume the part exists.
Three messages in one mailbox: an original whose body contains both a bare "From " line and an already-escaped ">From " line, the reply that threads to it, and the multipart/report bounce that reply triggered. mboxrd escaping is what makes the round trip lossless.
Failed tool invocation rows for agent error-handling and retry tests.
Intentionally invalid Python indentation for linter / parser error-path tests. Labelled intentionally invalid in title and description.
Intentionally corrupt JavaScript object literal — labelled invalid for error handling. Labelled intentionally invalid in title and description.
Intentionally invalid JSON (unquoted key + trailing) for strict parser failure tests. Labelled intentionally invalid in title and description.
Intentionally invalid YAML indentation for parser error fixtures. Labelled intentionally invalid in title and description.
Intentionally invalid Julia (unclosed function) for linter error-path tests.
Intentionally invalid Haskell (unterminated string) for parser failure tests.
Intentionally invalid Lua table for error handling.
Intentionally invalid R (unclosed call) for parser tests.
Intentionally invalid Clojure (unbalanced forms) for clj-kondo-style tests.
Intentionally invalid Fortran for compiler error fixtures.
Intentionally invalid Nim for nim check error paths.
Intentionally invalid Go syntax for gofmt/parser failure tests.
Intentionally invalid Rust for rustc error-path fixtures.
Intentionally invalid Python match (missing colon) for linters.
A deliberately invalid source map: version 2 instead of 3, a sources array longer than sourcesContent, a mapping segment that names an index outside `names`, and a `$` that is not in the base64 VLQ alphabet. For testing that a decoder validates the envelope before trusting the mappings.
The quoting rules that make ICU messages surprising: a single quote starts a literal section only when the next character is one ICU cares about, a doubled '' is always one apostrophe, and '#' inside a plural branch is a literal hash. Every message is paired with the exact string it must produce.
A German catalog carrying every state a PO entry can be in but the happy one: two fuzzy entries (one of them a plural) with #| previous-msgid comments, an entry that is present but untranslated, three obsolete #~ entries including an obsolete plural and an obsolete msgctxt entry, and two complete entries as the control.
Every escaping rule aapt2 enforces on a strings.xml, in one file: backslash-escaped apostrophes and quotes, quoted values that preserve leading whitespace, an escaped @ and ?, CDATA-wrapped inline HTML, <xliff:g> placeholder protection with examples, formatted="false", translatable="false" and a scoped tools:ignore.
SAMPLE HS256 JWT with a past exp claim — for expiry-validation harnesses.
Intentionally invalid JWT (truncated) for parser error-path tests.
Empty JWKS keys array for edge-case JWKS loaders.
SAMPLE OAuth error JSON for token-endpoint failure handling.
Intentionally misconfigured CORS SAMPLE (* + credentials) for policy linters.
OAuth 2.0 SAMPLE error JSON (invalid_grant) for client error-path tests.
OAuth 2.0 SAMPLE error JSON (invalid_client) for client error-path tests.
OAuth 2.0 SAMPLE error JSON (invalid_scope) for client error-path tests.
OAuth 2.0 SAMPLE error JSON (temporarily_unavailable) for client error-path tests.
OAuth 2.0 SAMPLE error JSON (insufficient_scope) for client error-path tests.
OAuth 2.0 SAMPLE error JSON (unauthorized_client) for client error-path tests.
A correctly signed leaf whose notAfter fell in the past (2020). The only thing wrong with it is the clock, which makes it the clean way to assert that an expiry error is reported as expiry and not as a signature failure.
The mirror of the expired leaf: identical in every respect except that notBefore is 2035, so it is rejected from the other side of the validity window. Pairs with it to prove a verifier distinguishes the two clock errors.
A valid, correctly chained certificate for the wrong host: both CN and SAN say wrong-host.pki.sample.example. Serve it for leaf.pki.sample.example to exercise the hostname-verification path on its own.
The certificate's CN is app.pki.sample.example but its only SAN is different.pki.sample.example. RFC 6125 clients must ignore the CN entirely, so this separates modern verifiers from ones still falling back to Common Name.
A pre-RFC 6125-style certificate carrying only a Common Name and no subjectAltName extension. Every current browser and most TLS libraries reject it outright, which makes it a precise legacy-compatibility probe.
An end-entity certificate that signs itself and chains to nothing — the shape a development server produces when nobody ran a CA. It is internally consistent, so the only defect a verifier can find is the missing trust anchor.
A leaf that is valid in every structural respect and revoked in the matching CRL and OCSP response shipped alongside it. It is the fixture that proves a client actually performs revocation checking rather than stopping at path building.
A correctly signed CRL with an absent revokedCertificates field — what a CA publishes when it has revoked nothing. Parsers that assume the list is always present tend to fault here rather than report zero entries.
A validly signed CRL whose nextUpdate passed in 2020. Whether a client hard-fails, soft-fails, or silently trusts stale revocation data is a real policy decision, and this is the fixture that reveals which one it made.
The OCSP counterpart of the CRL entry: status revoked for the revoked SAMPLE leaf, with the same 2026-03-01 revocation time and keyCompromise reason. Use both against the same certificate to check that CRL and OCSP paths agree.
The minimal unsuccessful OCSP response: responseStatus unauthorized and no responseBytes at all, which is what a responder returns for a certificate it does not serve. A handful of bytes that regularly breaks clients expecting a signed body.
The same leaf key and certificate in a PKCS#12 file with no password and no encryption. Several importers refuse an empty password, prompt anyway, or treat it as the literal empty string, so this is the fixture that finds out which.
An intentionally corrupt PKCS#10 request: the PEM armour is intact but four illegal characters have been substituted into the Base64 body, so decoding fails part-way. It exists to check that a CSR intake path reports a parse error instead of a stack trace or a partially populated record.
The legacy encrypted-key layout: PKCS#1 body plus `Proc-Type: 4,ENCRYPTED` and `DEK-Info` PEM headers carrying the cipher and IV, password `novus-p7-sample-pkcs1`. Parsers that strip PEM headers before decoding silently lose the IV and fail here.
Two keys of different types published under the same kid — what a botched key rotation leaves behind. A resolver that returns the first match silently verifies against the wrong key type instead of reporting the ambiguity.
A JWK Set whose keys carry no kid at all, which RFC 7517 permits. Verifiers must then fall back to trying candidates by algorithm, and the ones that index the set by kid alone find nothing.
A correctly signed RS256 token whose exp passed on 2020-01-01. The signature still verifies, so it isolates expiry handling from every other check — including the libraries that validate the signature and then forget to look at exp.
A valid signature over a claim set whose nbf is 2035. Many verifiers check exp diligently and skip nbf entirely, so this is the token that finds out.
The valid RS256 token with the last bit of its signature flipped. Header and payload are byte-identical to the valid twin, so any difference in outcome is entirely down to signature verification.
A perfectly well-formed RS256 signature made with the SAMPLE root key while the kid header still names the leaf key. Verifiers that trust the kid without checking the signature against that exact key accept it.
A genuinely valid RS256 signature whose kid names a key that has been rotated out of the JWK set. The right behaviour is a clean key-not-found error, not a silent fallback to whichever key happens to be first.
An unsecured JWS: alg is none and the signature segment is empty, leaving only the trailing dot. Any verifier that accepts it will accept a claim set an attacker wrote, which is why this is the first negative test to run.
The classic algorithm-confusion shape: a token that claims HS256 while its kid points at an RSA key, MACed with that key's public PEM as the shared secret. A verifier that picks its algorithm from the header rather than from the key type accepts it.
The EdDSA token with one bit of its signature flipped. Ed25519 verification either succeeds or fails with no partial credit, which makes this the cleanest possible negative case.
The same 12-case Novus Checkout run written the way maven-surefire 3.2 writes it. Maven Surefire merges its per-class files under a <testsuites> root and adds a <properties> block plus system-out/system-err on every suite. All eight dialect files in this group report 12 tests, 1 failure, 1 error and 1 skip, so a JUnit parser can be held to identical totals across every producer.
The same 12-case Novus Checkout run written the way pytest 8.2 --junitxml writes it. pytest emits a single <testsuite name="pytest"> whose classname is the dotted module path, and decorates each case with file and line attributes. All eight dialect files in this group report 12 tests, 1 failure, 1 error and 1 skip, so a JUnit parser can be held to identical totals across every producer.
The same 12-case Novus Checkout run written the way @playwright/test 1.47 junit reporter writes it. Playwright puts the run totals on the <testsuites> root, names each suite after its spec file, and uses the bare describe title as classname. All eight dialect files in this group report 12 tests, 1 failure, 1 error and 1 skip, so a JUnit parser can be held to identical totals across every producer.
The same 12-case Novus Checkout run written the way jest-junit 16 writes it. jest-junit repeats the whole "describe > it" title in both classname and name, which breaks dashboards that assume classname is a package. All eight dialect files in this group report 12 tests, 1 failure, 1 error and 1 skip, so a JUnit parser can be held to identical totals across every producer.
The same 12-case Novus Checkout run written the way Gradle 8.9 Test task writes it. Gradle writes hostname and timestamp on every suite and an empty self-closing <properties/> element that some parsers mishandle. All eight dialect files in this group report 12 tests, 1 failure, 1 error and 1 skip, so a JUnit parser can be held to identical totals across every producer.
The same 12-case Novus Checkout run written the way vitest 2.0 junit reporter writes it. Vitest names the root suite after the elapsed time and uses the spec file path as classname for every case. All eight dialect files in this group report 12 tests, 1 failure, 1 error and 1 skip, so a JUnit parser can be held to identical totals across every producer.
The same 12-case Novus Checkout run written the way go-junit-report 2.1 writes it. go-junit-report names each suite after a Go package and carries the toolchain version in a go.version property. All eight dialect files in this group report 12 tests, 1 failure, 1 error and 1 skip, so a JUnit parser can be held to identical totals across every producer.
The same 12-case Novus Checkout run written the way PHPUnit 11.2 --log-junit writes it. PHPUnit nests per-class suites inside a named parent suite and adds an assertions count that no other dialect reports. All eight dialect files in this group report 12 tests, 1 failure, 1 error and 1 skip, so a JUnit parser can be held to identical totals across every producer.
A clean green run: six passing cases, zero failures, errors and skips. The baseline a CI gate should treat as success, and the control case for any dashboard that colours a build from the failure count.
Three cases, one of them failing with an assertion message and a CDATA stack trace. The smallest report that must turn a build red, and the one to test a failure-summary renderer against.
Three failures spread across three different classes in one suite. Use it to check that a reporter lists every failure rather than stopping at the first, and that it groups them by classname rather than by suite.
One <failure> (an assertion that did not hold) and one <error> (an exception the test never expected), side by side. Parsers that collapse the two lose the distinction between a broken assertion and a broken environment.
A suite in which every case was skipped, so tests equals skipped and nothing actually ran. A gate that reads only the failure count calls this green; one that checks executed>0 catches it.
A structurally valid report containing a suite with no <testcase> children at all — what a runner writes when a filter matched nothing. Aggregators that divide by the test count to compute a pass rate hit a zero denominator here.
The full canonical run flattened into a single suite: nine passes, one failure, one error and one skip. This is the same twelve cases the eight dialect files carry, so totals can be compared straight across.
A case that failed on its first attempt and passed on the retry, recorded with Surefire's <flakyFailure> child. The suite counters say zero failures, so a parser that ignores the extension element reports a clean run and loses the flake entirely.
A skipped case whose reason appears twice — in the message attribute and again as CDATA text inside the <skipped> element. Reporters that read only the attribute silently drop the longer explanation.
A failure whose message contains an expected/actual diff with angle brackets and newlines, the shape assertion libraries actually produce. Good for checking that a dashboard escapes the message for HTML and keeps its line breaks.
Three suites under a <testsuites> root whose own attributes already hold the aggregate totals. A parser that sums the children and also trusts the root double-counts every case, which is the classic cause of a dashboard reporting 24 tests for a 12-test run.
The single-suite form Gradle and Ant write: the root element is <testsuite> with no <testsuites> wrapper at all. Parsers hardcoded to descend from <testsuites> read this file as empty rather than failing, so it silently reports a run of zero tests.
Captured stdout and stderr wrapped in CDATA, where the stdout text itself looks like XML markup. A parser must treat the CDATA content as opaque characters; one that re-parses it finds a <report> element that does not exist.
Test names containing &, <, >, quotes and an apostrophe, escaped as XML requires. Round-tripping this report through a converter is the fastest way to find double-escaping bugs that turn & into &amp; one hop at a time.
A report from a runner that never records durations: neither the suite nor any case carries a time attribute. Dashboards that parse time unconditionally throw here, and ones that default it to zero quietly report a suite that took no time at all.
The same classname and name appear twice with different outcomes — what a parameterised runner or a merged report can produce. Any store keyed on classname+name overwrites the first result and reports the suite as green or red depending purely on document order.
Durations written four different ways in one file: scientific notation, a comma decimal separator from a German-locale JVM, a bare integer, and a comma that could be either a decimal point or a thousands separator. A parser using a locale-sensitive number reader gets a different answer depending on where it runs.
Build #101 of five consecutive runs of checkout.SessionTest, in which expiresSessionAfterTimeout is passing while the other five cases pass every time. The underlying cause is a 250 ms sleep racing the session expiry sweep. Read the whole family in build order to reproduce what a flake detector sees.
Build #102 of five consecutive runs of checkout.SessionTest, in which expiresSessionAfterTimeout is failing while the other five cases pass every time. The underlying cause is a 250 ms sleep racing the session expiry sweep. Read the whole family in build order to reproduce what a flake detector sees.
Build #103 of five consecutive runs of checkout.SessionTest, in which expiresSessionAfterTimeout is passing while the other five cases pass every time. The underlying cause is a 250 ms sleep racing the session expiry sweep. Read the whole family in build order to reproduce what a flake detector sees.
Build #104 of five consecutive runs of checkout.SessionTest, in which expiresSessionAfterTimeout is failing while the other five cases pass every time. The underlying cause is a 250 ms sleep racing the session expiry sweep. Read the whole family in build order to reproduce what a flake detector sees.
Build #105 of five consecutive runs of checkout.SessionTest, in which expiresSessionAfterTimeout is passing while the other five cases pass every time. The underlying cause is a 250 ms sleep racing the session expiry sweep. Read the whole family in build order to reproduce what a flake detector sees.
The answer key for the timing race family: the flake rate a detector should derive from the five build reports next to it. Exactly one of the six tests is unstable, at a rate of 2/5; the other five are stable at 0.00.
Build #201 of five consecutive runs of cart.DiscountTest, in which stacksDiscountsInDeclaredOrder is passing while the other five cases pass every time. The underlying cause is a shared coupon cache left populated by a sibling test under random ordering. Read the whole family in build order to reproduce what a flake detector sees.
Build #202 of five consecutive runs of cart.DiscountTest, in which stacksDiscountsInDeclaredOrder is failing while the other five cases pass every time. The underlying cause is a shared coupon cache left populated by a sibling test under random ordering. Read the whole family in build order to reproduce what a flake detector sees.
Build #203 of five consecutive runs of cart.DiscountTest, in which stacksDiscountsInDeclaredOrder is failing while the other five cases pass every time. The underlying cause is a shared coupon cache left populated by a sibling test under random ordering. Read the whole family in build order to reproduce what a flake detector sees.
Build #204 of five consecutive runs of cart.DiscountTest, in which stacksDiscountsInDeclaredOrder is passing while the other five cases pass every time. The underlying cause is a shared coupon cache left populated by a sibling test under random ordering. Read the whole family in build order to reproduce what a flake detector sees.
Build #205 of five consecutive runs of cart.DiscountTest, in which stacksDiscountsInDeclaredOrder is passing while the other five cases pass every time. The underlying cause is a shared coupon cache left populated by a sibling test under random ordering. Read the whole family in build order to reproduce what a flake detector sees.
The answer key for the order dependent family: the flake rate a detector should derive from the five build reports next to it. Exactly one of the six tests is unstable, at a rate of 2/5; the other five are stable at 0.00.
Build #301 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is errored while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
Build #302 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is passing while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
Build #303 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is passing while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
Build #304 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is passing while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
Build #305 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is errored while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
The answer key for the network dependency family: the flake rate a detector should derive from the five build reports next to it. Exactly one of the six tests is unstable, at a rate of 2/5; the other five are stable at 0.00.
Build #401 of five consecutive runs of cart.PricingTest, in which appliesTaxToSubtotal is failing while the other five cases pass every time. The underlying cause is a rounding boundary that only trips when the tax rate table is reloaded. Read the whole family in build order to reproduce what a flake detector sees.
Build #402 of five consecutive runs of cart.PricingTest, in which appliesTaxToSubtotal is failing while the other five cases pass every time. The underlying cause is a rounding boundary that only trips when the tax rate table is reloaded. Read the whole family in build order to reproduce what a flake detector sees.
Build #403 of five consecutive runs of cart.PricingTest, in which appliesTaxToSubtotal is quarantined while the other five cases pass every time. The underlying cause is a rounding boundary that only trips when the tax rate table is reloaded. Read the whole family in build order to reproduce what a flake detector sees.
Build #404 of five consecutive runs of cart.PricingTest, in which appliesTaxToSubtotal is quarantined while the other five cases pass every time. The underlying cause is a rounding boundary that only trips when the tax rate table is reloaded. Read the whole family in build order to reproduce what a flake detector sees.
Build #405 of five consecutive runs of cart.PricingTest, in which appliesTaxToSubtotal is quarantined while the other five cases pass every time. The underlying cause is a rounding boundary that only trips when the tax rate table is reloaded. Read the whole family in build order to reproduce what a flake detector sees.
The answer key for the quarantined after two failures family: the flake rate a detector should derive from the five build reports next to it. Exactly one of the six tests is unstable, at a rate of 5/5; the other five are stable at 0.00.
Forty builds of six tests, one JSON object per line, with three tests that fail intermittently and three that never do. This is the input shape a flake detector ingests; the CSV twin in this group holds the aggregate it should produce.
The canonical TAP shape: a version line, a leading plan, then six passing assertions in order. Anything a TAP consumer does with a real stream it must do with this one first.
The same stream with the plan at the end, which is what a harness emits when it does not know the test count up front. A consumer that requires a leading plan rejects a perfectly valid stream.
Two failing assertions, each followed by an indented YAML diagnostic block carrying the expected and actual values and a file/line location. The block is where every useful failure message in TAP lives, and it is the part naive line-based parsers throw away.
A run abandoned after the third assertion with a Bail out! line, leaving five of the planned eight assertions unreported. The run is a failure even though only one assertion said not ok, and a consumer must not report 2/3 passing as a 67% pass rate.
Free-form # comment lines interleaved with assertions, including a trailing summary block. Comments carry no result and must never shift assertion numbering, which is exactly what a parser counting lines instead of ok/not ok tokens gets wrong.
Every assertion in this stream says ok, but the plan promised ten and only eight arrived — the signature of a runner that crashed after its last reported assertion. A consumer that only counts not ok lines calls this a clean pass.
Two assertions marked # SKIP with a reason, alongside a genuine failure. Skipped assertions are written as ok, so counting ok lines reports 5 passes when only 3 tests actually ran.
Two failing assertions marked # TODO, meaning they are known-unfinished work rather than regressions. A TODO failure must not fail the run, so a consumer that treats every not ok as a build breaker turns this green run red.
Assertion 2 is marked TODO but reports ok — an unexpected success, which means the feature landed and the marker is now stale. Harnesses such as prove report this as a bonus rather than a pass, and dropping the distinction lets stale TODOs accumulate forever.
A whole suite declined in a single line: a zero-length plan with a SKIP directive and a reason. It is a valid, complete TAP stream containing no assertions, and a consumer must report it as skipped rather than as an empty pass or a parse error.
Two subtests, each an indented TAP stream with its own plan, rolled up into two top-level assertions. Flatten it and you count seven assertions instead of two; ignore the indentation and the nested failure is counted twice.
TAP 14 with an explicit version line and a pragma inside a subtest. Consumers pinned to version 13 either reject the stream outright or ignore the pragma, so this file separates the two behaviours.
The same six pickles reported as JUnit XML, which is what a BDD suite hands to a generic CI dashboard. One <testcase> per pickle means the three expanded outline rows appear as three tests with identical names — enough to break any store keyed on name alone.
One step of one scenario fails with an assertion message and a stack frame; every other step passes. In cucumber.json a scenario has no status of its own — it is failed if any of its steps is — so this file catches reporters that look for a scenario-level field that does not exist.
The three non-failure statuses BDD runners produce and dashboards routinely collapse into "failed": undefined (no step definition matched), pending (explicitly unimplemented) and skipped (never attempted). Whether the run is red depends on the runner's strict setting, which is exactly the decision this file forces.
The messages twin of the failing run: one testStepFinished carries status FAILED with both a human message and a structured exception object, and testRunFinished reports success false. Comparing it with the passing stream in the other group isolates exactly which envelopes a failure changes.
The NUnit 3 test-run document, with a nested Assembly/TestFixture suite tree, an environment element and per-case seeds. NUnit has no separate error outcome, so the errored case appears as Failed with label="Error" and the report reads failed=2. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
The `dotnet test` TRX document in full: Times, TestSettings, Results, TestDefinitions, TestEntries, TestLists and a ResultSummary with sixteen counters. Results and definitions are joined on GUIDs, so a converter that reads only <Results> loses every class name. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
Playwright's native JSON report, four levels deep: suites contain specs, specs contain tests (one per project) and tests contain results (one per attempt). Its stats use expected/unexpected rather than passed/failed, because a test annotated as expected-to-fail counts as expected when it fails. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
Jest's --json output, where skipped tests are called pending and the totals appear as flat numTotal/numPassed/numFailed fields alongside per-file assertionResults. Timestamps are epoch milliseconds rather than ISO strings, which is the field most converters mis-handle. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
Mocha's JSON reporter, which lists every test in a tests array and then repeats each one in passes, failures or pending. Summing all four arrays counts the run twice — this file exists so that bug shows up on a 12-test suite instead of in production. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
Robot Framework's output.xml, in which every keyword call carries its own status element and a trailing statistics section restates the totals by tag and by suite. Robot 7 reports elapsed seconds rather than the endtime attribute older versions used, so schemaversion is what a reader must branch on. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
TestNG's own result document, with suite/test/class/test-method nesting, signature attributes and full stack traces in CDATA. TestNG has no error status, so the errored case is reported as FAIL and the header attributes read failed=2. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
The xUnit.net v2 shape: an <assemblies> root holding one assembly, whose tests are grouped into collections rather than classes. Result values are Pass, Fail and Skip with capital initials, which trips converters doing a case-sensitive comparison against the lowercase values every other format uses. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
The pytest-json-report document, which records setup, call and teardown as three separate phases per test and keeps error distinct from failed in its summary. A test can pass its call phase and still error in teardown, which is why summing outcomes without reading the phases gives the wrong total. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
An intentionally corrupt JUnit report: the file ends in the middle of a testcase attribute value, exactly as it would if the CI worker were killed while the reporter was still writing. Three elements are left unclosed and the document is not well-formed XML. A parser must fail loudly rather than report the two complete cases as the whole run.
An intentionally corrupt LCOV tracefile: every record declares LH eight greater than LF, so more lines were hit than exist. The syntax is perfectly valid, which is the point — the contradiction is semantic, and a coverage gate that trusts the summary counters computes over 100% coverage and passes a build it should have stopped. Recompute LH from the DA lines and the real figure is 127/140.
The same change as the unified twin, emitted in the pre-unified context format: `*** before` and `--- after` blocks separated by a row of asterisks, with `!`, `+` and `-` change markers. Parsers that assume every diff starts with `---`/`+++` misread this one as a unified diff with no hunks.
The default output of bare `diff`: ed-style commands such as `3a4` with `<` and `>` bodies and no file headers at all. Tooling that identifies diffs by looking for `---`, `+++` or `@@` cannot even tell this is a diff, which is exactly what makes it a useful negative fixture.
Quilt, Debian and vendor trees check patches into the repository, so editing one produces a diff whose body is itself full of `+++`, `---` and `@@` lines and whose section heading is a `diff --git` line. Any scanner that finds file boundaries by searching for those tokens anywhere in the stream splits this single-file diff into several phantom files.
A patch as it actually arrives in a mailing-list message: prose above it, a sign-off and an email signature below it, and a signature separator that looks like the start of a deletion. Extractors must find the diff without swallowing the surrounding text.
format-patch output for a commit created with `--allow-empty`: full mail headers, a commit message, the `---` separator, and then straight to the signature with no diffstat and no diff. Pipelines that treat 'no diff found' as a parse error reject a message that git itself considers valid.
The commit message uses `---` as a horizontal rule, so the file contains two lines that look like the diffstat separator. git's own mailinfo ends the message at the FIRST one, which quietly truncates the message and drops the rounding table — the patch still applies, but the recorded history is wrong.
An intentionally invalid patch: the file ends three lines into a hunk that declares many more, as it would after a truncated download or a mail client cutting the message. Nothing is corrupt at the byte level, so a parser must notice the count mismatch rather than applying a partial hunk.
An intentionally invalid patch whose hunk header claims 99 lines on each side while the body supplies far fewer. Every other byte is a well-formed patch, so this isolates one question: does the applier verify the declared counts, or does it trust them and read past the end of the hunk?
What `git show` prints for a merge commit: a `diff --cc` header, an index line naming three blobs, `@@@` hunk markers, and two prefix columns instead of one. The `++` line is the giveaway a reviewer is looking for — content that appears in the merge result but in neither parent.
An octopus merge, so the hunk marker grows to `@@@@` and every line carries three prefix columns. Any parser that hard-codes `@@@` or assumes two columns reads the third column as the first character of the line's content.
When the file mode differs between the parents and the merge result, a combined diff adds a `mode a,b..result` line below the index line — a comma-separated shape that appears nowhere else in git's output. Parsers written for the single-parent `old mode`/`new mode` pair do not recognise it.
A working-tree file left mid-merge in git's default `merge` conflict style: our version, a row of equals signs, their version, and branch labels on the opening and closing markers. Both sides happen to end with the same line, which the zdiff3 twin in this group hoists out and this style repeats.
The same conflict with `merge.conflictStyle=diff3`, which inserts the merge base between the two sides behind a row of pipes. Tools that split a conflict on `=======` alone silently fold the ancestor text into the ours side.
The identical merge under `merge.conflictStyle=zdiff3`, which hoists lines common to both sides out of the conflict region — here 'jitter: on' moves below the closing marker. Diff this against the diff3 twin to see that the same conflict produces different file contents depending on one config value.
One file left with three independent unresolved regions and clean text between them, which is what a real deployment-values merge looks like. Editors that jump to 'the next conflict' and resolvers that report a boolean rather than a count both get exercised here.
A package manifest left mid-merge, so the file is intentionally invalid JSON: conflict markers sit inside the dependencies object. Any tool that reads manifests has to fail on this with a message about the conflict rather than a bare syntax error at line 5.
Documentation about merge conflicts that quotes the markers inside a fenced code block, and then genuinely conflicts further down. A pre-commit hook that greps for `^<<<<<<<` reports two hits and blocks a clean commit; one that understands Markdown fences reports the one that matters.
Someone committed a file that still contained conflict markers, and merging that commit produced markers inside markers. Region matchers that pair the first `<<<<<<<` with the first `=======` split this file in the wrong place and produce two overlapping regions that cannot both be resolved.
What `git apply --reject` leaves behind when a hunk will not apply: the failed hunks alone, under a header that is neither `diff --git` nor a plain `---`/`+++` pair. Ships with its .orig twin so the pair can drive a resolve-the-reject workflow end to end.
The message template git writes into .git/MERGE_MSG when a merge stops on conflicts: one real subject line followed by a commented list of the conflicted paths and the standard advice block. Everything after the first blank line is stripped by `git commit`, so a hook that lints the whole file rejects messages git would accept.
An intentionally invalid ownership file carrying five defects that all parse as plausible lines: an owner that is neither a handle nor an email, a team with no organisation, a character class, a negation, and a path with an unescaped space. Each is a separate assertion for a linter, and none of them is a syntax error a naive line splitter would notice.
A commit message file exactly as `git commit` hands it to a commit-msg hook: a conventional subject, a wrapped body, two trailers, and git's own comment block that the hook must ignore. The subject is 43 characters, comfortably inside commitlint's default 72-character header limit.
A breaking change announced twice, which the specification allows: a `!` after the scope and a `BREAKING CHANGE:` footer whose value continues onto a second line. Generators that stop a footer at the first newline lose half the sentence, and version bumpers that only look for one of the two markers under-bump the release.
An intentionally invalid commit message that breaks four commitlint rules at once: no conventional type, a 116-character header, no blank line separating subject from body, and a body that starts mid-sentence. Every rule should fire independently, which is what makes this useful for checking that a linter reports all violations rather than stopping at the first.
A failed checkout: an upstream payment timeout sets ERROR status on four spans up the chain and attaches an exception event whose exception.stacktrace attribute holds a real multi-line Python traceback with embedded newlines. The fixture for error grouping, status propagation and multi-line attribute rendering.
Two hosts whose clocks disagree by 12 ms, so a server span appears to start before the client span that called it. Nothing in the payload is malformed — this is the most common real cause of a negative-latency gap in a waterfall, and viewers must show it rather than crash or silently reorder.
The checkout trace with one intermediate span dropped, as happens when an exporter's queue overflows. Three spans now reference a parent that is not in the payload — a partial trace that a store must render rather than reject.
Two different spans share one span ID inside a single trace, which the specification forbids. Intentionally invalid: it is the fixture for the de-duplication path, where a naive store silently overwrites one span with the other and loses a subtree.
A trace whose trace ID and root span ID are all zeroes — the value an uninitialised context produces. Intentionally invalid: the specification defines all-zero IDs as invalid, so a conformant receiver must reject the spans instead of creating a permanent bucket that every broken service writes into.
One span ends 8.4 ms before it started and another has identical start and end timestamps. Intentionally invalid: negative durations poison latency aggregates — a single one can drag a p99 below zero — so this is the fixture for the validation that must sit in front of any duration metric.
An OTLP/JSON export cut off in the middle of an object, the way a file sink looks when the collector is killed mid-write. This file is intentionally corrupt and small: it exists so an ingestion path can be tested for a clean parse error with a byte offset instead of a hang or a half-committed batch.
A labelled set of traceparent header values: four that must parse — including a future version with extra fields, which parsers are required to accept — and eight that must be rejected, covering all-zero IDs, version ff, short and uppercase trace IDs, and missing or trailing fields.
One label set exposed twice, a second pair that is only a duplicate once labels are sorted, and a repeated HELP line. Intentionally invalid: a scrape must fail rather than let last-write-wins decide which of two values for the same series survives.
Two histogram families that are syntactically fine and semantically wrong: one has non-monotonic buckets and no +Inf bucket, the other reports a _count larger than its +Inf bucket. Intentionally invalid, because histogram_quantile over either produces a confidently wrong number rather than an error.
Samples exposed with no HELP or TYPE at all, metadata arriving after the sample it describes, blank and whitespace-only lines and a bare comment. All of it is legal — metadata is optional — and all of it breaks parsers that assume every sample is introduced by a TYPE line.
A scrape body with metadata but no samples, which is what a freshly started process returns before it has recorded anything. Valid, and routinely mistaken for a failed scrape by code that treats an empty result as an error.
A document that parses perfectly as Prometheus text and is invalid as OpenMetrics, because the mandatory # EOF terminator is missing. That marker is the format's only defence against a truncated response being accepted as complete — which is the exact failure this file reproduces.
The error envelope a Prometheus API returns for a malformed PromQL query — status, errorType, a message with a line and column position, and an empty but present data object. Clients that only check for a data key render this as a successful empty result.
Java, Python and Go stack traces carried inside JSON string fields with their newlines escaped — the shape a structured logger produces, and the one that defeats multi-line joining rules written for plain text. Includes a Caused by chain and a goroutine dump.
Three hosts writing to one stream with disagreeing clocks: one 45 seconds behind and one six hours ahead because NTP is unreachable. Interleaved by host, so a naive tail shows events from the future and a retention window silently drops the past.
Twelve complete JSON records followed by a thirteenth cut off after 96 bytes with no trailing newline, exactly as a container log looks when the process is killed mid-write. Intentionally corrupt and small: a tailer must hold the partial line for a continuation rather than emit or discard it.
Two records containing unpaired \ud800 and \udfff escapes between three well-formed ones, plus a correct surrogate pair for comparison. Intentionally invalid: the escapes are syntactically legal JSON but cannot be encoded as UTF-8, which is where a re-serialising pipeline breaks.
A JSON Lines file with the debris a real container stream carries: blank and whitespace-only lines, one bare stderr write from a C library, a mid-file byte-order mark and two lines that are valid JSON but not objects. Five real records are in there.
A Spring-style text log where two stack traces span many physical lines. Eight logical events across a larger number of lines, so a shipper's multi-line rule — anything not starting with a timestamp continues the previous event — can be scored against a known answer.
A Go panic followed by the runtime's full goroutine dump — four goroutines with their wait states, two-line frames and a created by attribution, separated by blank lines. Blank-line separation defeats multi-line rules that treat an empty line as the end of an event.
A Rust panic surrounded by ordinary tracing output: the panic location with line and column, a six-frame numbered backtrace where every frame spans two lines, and the RUST_BACKTRACE note. Frame numbering and the deep indent are what a generic stack parser gets wrong here.
A .NET exception whose inner exception is introduced by the ---> marker and closed by End of inner exception stack trace, wrapped in pipe-delimited log lines. Error groupers that key on the outermost message alone merge two genuinely different faults here.
Four log lines where the last has no terminating newline — the normal state of any file still open for append. A tailer that only emits on seeing a newline holds that fourth line forever, which is why the newest error is the one missing from the dashboard.
The smallest CycloneDX document that is still valid: required metadata, one fictional component, and no dependencies array — for testing that a reader handles an SBOM with nothing optional present. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CycloneDX SBOM whose author names and properties contain accented Latin, CJK, right-to-left Hebrew, emoji and a deliberately long property value — for testing encoding handling and field-width assumptions. Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally corrupt CycloneDX SBOM: a valid 1.6 document cut off mid-object so the JSON never closes. Small on purpose — it exists to check that a reader fails cleanly instead of half-loading a component list. Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally invalid CycloneDX SBOM: the JSON parses, but bomFormat is missing, one component has no name, and a dependency references a bom-ref that no component declares. Every package, version, hash and licence is fictional — the tree describes nothing real.
An SPDX 2.3 tag-value document with only the mandatory document header and a single fictional package — no relationships, no files — for testing that a parser accepts a document with every optional block absent. Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally corrupt SPDX tag-value document, cut off part-way through a tag name so the final line has no colon or value. Kept small on purpose. Every package, version, hash and licence is fictional — the tree describes nothing real.
The transitional npm v2 lockfile, which carries BOTH the v3 packages map and the legacy nested dependencies tree describing the same fictional install — the case where a parser must not double-count. Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally invalid npm lockfile: two fictional packages carry sha512 integrity strings that cannot match their resolved tarballs — one derived from the wrong version, one a padded placeholder. Every package, version, hash and licence is fictional — the tree describes nothing real.
An npm lockfile where the fictional example-cache pins a peer of example-logger@2.9.0 while the rest of the tree resolves 3.4.1, forcing a nested node_modules duplicate — the shape a deduplication report must detect. Every package, version, hash and licence is fictional — the tree describes nothing real.
A modern Yarn Berry lockfile: YAML-shaped with an __metadata header, npm: protocol resolutions and cache-key-prefixed checksums — deliberately different from the Classic file in the same family. Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally corrupt Cargo.lock: a valid version 4 lockfile cut off inside a [[package]] table so the final key/value pair is incomplete. Small on purpose. Every package, version, hash and licence is fictional — the tree describes nothing real.
go.sum content: two h1: lines per fictional module — one for the module zip and one for its go.mod — which is the pairing a verifier must require. Served as .txt because go.sum has no registered media type. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Bundler lockfile in its indentation-significant block format — specs nested under GEM, transitive requirements nested one level deeper, and the BUNDLED WITH version on its own indented line. Every package, version, hash and licence is fictional — the tree describes nothing real.
An Elixir mix.lock: a literal Elixir map whose values are tuples of atoms, strings and lists. It is neither JSON nor TOML, so a generic lockfile reader has to special-case it. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Trivy-shaped image report with three result blocks — OS packages, language packages and a Dockerfile misconfiguration — so a parser must handle a Results array whose members have different keys. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
A clean scan report — the case dashboards get wrong. Trivy omits the Vulnerabilities key entirely rather than emitting an empty array, so a reader that assumes the key exists throws on a passing build. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
An intentionally corrupt scanner report: a valid Trivy-shaped JSON document cut off inside the first finding, for testing that a CI gate fails the build rather than reporting zero vulnerabilities. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
The console table a scanner prints, in fixed-width columns — the output people actually paste into tickets, and the one a log scraper has to parse without a delimiter. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
An intentionally invalid OSV record: the JSON parses, but the required id is missing, modified is not an RFC 3339 timestamp, the SEMVER range has a fixed event with no introduced event, and severity.score is a number where the schema demands a CVSS vector string. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
The legacy npm audit shape — numeric advisory ids, a separate actions array and dependency paths written with '>' — which tools built for the v2 report silently read as zero findings. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
A pip-audit report for the fictional Python packages. It deliberately carries no severity field — pip-audit does not assign one — which is the case a severity gate must handle without defaulting to critical. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
The XML twin of the Dependency-Check report — the form most Maven and Jenkins integrations consume — carrying the same four SAMPLE findings inside a namespaced analysis element. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
The shape a hosted dependency-alert API returns: alerts with lifecycle state, a nested advisory, a patched-version pointer and an explicitly null dismissed_reason on the alerts that were not dismissed. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
An intentionally corrupt DSSE envelope: the JSON parses and the signature block looks complete, but the payload is truncated and contains characters outside the base64 alphabet. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
A transparency-log entry keyed by its own UUID at the top level — a shape that breaks parsers expecting a fixed root key — with a base64 body that decodes to a dsse record. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
The oldest supply-chain artifact there is: a sha256sum manifest with the exact two-space separator the tool emits, listing a fictional release tarball and its nine dependency archives. Every package, version, hash and licence is fictional — the tree describes nothing real.
An ASCII-armored detached signature block of the shape that accompanies a SHA256SUMS file. It is a SAMPLE placeholder, not a valid OpenPGP signature — armor detectors will find it, verifiers must reject it. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
A dependency graph containing a genuine three-node cycle between fictional plugins — the fixture that makes a naive recursive walker hang or blow the stack, with the cycle path stated so the expected answer is unambiguous. Every package, version, hash and licence is fictional — the tree describes nothing real.
The cyclic plugin graph as DOT, with the three cycle edges highlighted. Graphviz renders it happily, which is exactly why a topological sort must be the thing that rejects it. Every package, version, hash and licence is fictional — the tree describes nothing real.
The territory as GML 3.2 with an EPSG URN srsName — which means latitude comes first, the opposite of GeoJSON. This is the single most common cause of features landing in the wrong hemisphere, so the file is built to catch it.
A single Feature whose geometry is a GeometryCollection of a Point, a LineString and a Polygon. Many simple readers flatten or silently drop these, and many writers cannot produce them at all, so it is the usual place a conversion loses data.
RFC 7946 permits `"geometry": null` for a feature with attributes but no location. Readers that assume every feature has coordinates crash here, and writers that emit an empty Point instead corrupt the record's meaning.
A top-level Geometry object with no Feature or FeatureCollection around it. This is legal GeoJSON and is what PostGIS `ST_AsGeoJSON` returns, but a surprising number of importers only accept a FeatureCollection.
One Feature at the top level, with properties and an id but no enclosing collection — the shape a single-record API response takes. Pair it with the bare-geometry fixture to find readers that only handle one of the three legal root types.
A structurally valid FeatureCollection with an empty `features` array — what a spatial query legitimately returns when nothing matches. It is the standard fixture for the empty-state path of a map component.
One feature with `"properties": {}`, one with `"properties": null` and one fully populated. Both empty forms are legal, and attribute-table writers routinely fall over on the null form when they try to enumerate its keys.
A two-point line whose longitudes step from 179.6 to -179.7. Interpolating naively draws a 359.3-degree line all the way back around the world instead of the 0.7-degree hop across the 180th meridian — the classic antimeridian artefact.
The same transect cut at the 180th meridian into a two-part MultiLineString, which is what RFC 7946 section 3.1.9 recommends. The split latitude is the linear interpolation of the unsplit twin, so the two files describe the same ground path.
A rectangle whose east edge is at 179.7 W and west edge at 179.6 E. Read literally in planar coordinates it wraps the entire globe and inverts the inside/outside test, so point-in-polygon queries return the exact opposite of the truth.
The straddling block cut at 180 into two polygons that share an edge on the meridian — the interoperable form. Use it as the expected output when testing an antimeridian-splitting routine against the unsplit twin.
The same transect with its eastern end written as 180.3 rather than the normalised -179.7. Producers that accumulate longitudes across the antimeridian emit this constantly; RFC 7946 restricts longitude to -180..180, so a strict reader must reject or normalise it.
Three points at exactly plus or minus 90 degrees latitude, two of which are the same physical place written with different longitudes. Web Mercator cannot represent either pole — latitude 90 projects to infinity — so this is the fixture that catches divide-by-zero and NaN in a reprojection path.
A ring that encloses the north pole by running along 85 N and closing across the top of the graticule. Planar area and centroid routines return meaningless answers here, and many renderers draw a rectangle rather than a cap.
A flight path that goes up one meridian, touches the pole, and comes down the antipodal meridian — so longitude jumps by exactly 180 degrees at the middle vertex. Renderers that interpolate in longitude draw a horizontal streak across the whole map instead.
Intentionally invalid: the parcel's exterior ring omits the repeated closing position that RFC 7946 requires. Many readers close it silently, which hides the producer's bug until a stricter consumer downstream rejects the data.
Both rings of the Mill Court parcel are wound the wrong way round: the exterior clockwise, the interior counter-clockwise. RFC 7946 mandates the right-hand rule, and consumers that rely on winding to tell holes from shells will read this polygon inside out.
Intentionally invalid: a bowtie ring whose two lobes wind in opposite directions, so the shoelace areas nearly cancel. Buffer, intersection and area operations on this geometry return nonsense rather than failing, which is why it belongs in a validation suite.
Intentionally invalid: a ring of three positions that closes back on itself and therefore encloses nothing. RFC 7946 requires at least four positions for a linear ring, and this is the shape a simplification pass produces when it over-thins a small polygon.
Intentionally invalid: the second ring is a whole separate parcel filed as an interior ring of the first, which OGC Simple Features forbids. It is what happens when a MultiPolygon is flattened into a Polygon by concatenating rings.
A feature carrying a LineString with an empty coordinate array. Empty geometries are what spatial operations legitimately return — an intersection that misses, a clip that removes everything — and index and rendering code routinely assumes at least one coordinate exists.
A feature carrying a Polygon with no rings at all. Empty geometries are what spatial operations legitimately return — an intersection that misses, a clip that removes everything — and index and rendering code routinely assumes at least one coordinate exists.
A GeometryCollection with an empty `geometries` array — structurally valid, semantically the empty geometry. Converters that map a collection onto a multi-geometry type usually emit null here, quietly changing the record's meaning.
Intentionally invalid: a point at longitude 200. It is a plausible-looking number that usually comes from adding an offset without wrapping, and it survives JSON schema checks that only test for `number`.
Intentionally invalid: latitude 95, five degrees past the north pole. This is the value that appears when longitude and latitude have been swapped somewhere upstream, so catching it early usually finds an axis-order bug rather than a data-entry one.
Intentionally invalid: the file is perfectly good JSON but the coordinates are quoted strings, which RFC 7946 does not allow. It is exactly what a CSV-to-GeoJSON script produces when it forgets to cast, and a permissive reader will coerce it and hide the bug.
The same territory quantized to only 100 steps, so rounding error reaches roughly 220 m and several vertices collapse onto the same grid cell. Use it to prove that a tolerance in your comparison code is actually being applied rather than accidentally passing.
Intentionally invalid: East Field references the shared arc forwards when it should use the reversed form, so its ring no longer closes. This is the single most common hand-editing mistake in TopoJSON, and it produces a plausible-looking file that renders as a torn shape.
A topology whose fourth arc repeats the same position twice, giving a line of zero length. Quantization produces these routinely when two vertices land in the same grid cell, and simplification code that divides by segment length fails on them.
The same 24 points split into two `trkseg` elements with a ten-minute gap between them — what a receiver writes after a stop or a signal loss. Tools that concatenate segments without noticing the boundary report a moving average dragged down by a pause that never happened on the move.
The same eight trackpoints written to the GPX 1.1 schema. The two versions differ in namespace and in where document metadata lives — 1.1 wraps it in a `metadata` element, 1.0 puts name, desc and time directly under `gpx` — which is exactly what a namespace-hardcoding reader gets wrong.
The same eight trackpoints written to the GPX 1.0 schema. The two versions differ in namespace and in where document metadata lives — 1.1 wraps it in a `metadata` element, 1.0 puts name, desc and time directly under `gpx` — which is exactly what a namespace-hardcoding reader gets wrong.
Eight trackpoints with timestamps but no `ele` element, the shape a receiver writes on a 2D fix. Elevation-profile code that assumes the element is present either crashes or charts a flat line at zero, which looks like real data.
The same eight points with elevation but no `time` element — what you get when a track is drawn in a planning tool rather than recorded. Speed and pace calculations must refuse to produce a number here instead of dividing by a zero duration.
The same eight points timestamped with a +01:00 offset rather than the usual Z. The digits are identical to the reference track, so a parser that strips the offset and assumes UTC produces times that are wrong by exactly one hour — a silent error that only shows up when two traces are merged.
A track containing exactly one point, which is what a receiver writes when a recording is stopped immediately. Distance, speed and bearing all need a pair of points, so this is the fixture that finds off-by-one loops and empty-slice crashes.
Seven trackpoints whose timestamps go forwards, backwards, and then repeat — the pattern a receiver produces after a clock correction or a buffered replay. Naive speed calculations divide by a negative or zero time delta and emit impossible values.
Six cycles of a receiver that has power but no satellite lock: GGA fix quality 0, RMC status V, and empty coordinate fields throughout. Parsers that split on commas and index positionally read these empty fields as zeros and plot the track at Null Island.
A log with one sentence whose checksum has been altered and a final sentence truncated mid-transmission with no checksum at all — the two ways a serial GPS feed actually degrades. A correct parser drops both and keeps everything else.
NMEA never writes a negative coordinate: sign lives entirely in the N/S and E/W letters, and the numeric field is always positive. This log sits in the southern and eastern hemispheres, so a parser that ignores the hemisphere letter puts every fix in the wrong quadrant of the world.
The same sentences terminated with a bare LF rather than the CR LF the standard mandates — what you get after a log passes through a text editor or a Unix pipeline. Parsers that strip only "\r\n" leave a stray character on every line and then fail the checksum.
Two polygons that each carry an `innerBoundaryIs` ring: a parcel with a courtyard and a lake with an island. KML names its rings explicitly instead of relying on winding order, so converting to GeoJSON means deciding the winding rather than copying it.
One Placemark whose MultiGeometry mixes three Points with a LineString. GeoJSON has no equivalent single type for a heterogeneous set, so this must become a GeometryCollection — and converters that reach for MultiPoint instead lose the line.
A georeferenced GroundOverlay pinned to the territory's bounding box and a ScreenOverlay anchored to a pixel position. Both reference images that are not present, which is the normal state for a bare .kml and the reason KMZ exists.
A KMZ that contains a second KML in a subdirectory, reached through a `NetworkLink` with a relative href, plus an overlay image two directories deep. Readers that only load `doc.kml` show the overlay but none of the three parcels.
A point with an M (measure) ordinate rather than a Z. Written without the tag this is indistinguishable from a Z geometry, and a parser that assumes the third ordinate is elevation silently converts a 345-second measure into a 345-metre altitude.
One EMPTY value for each WKT geometry type, one per line. Empty geometries are what spatial operations return when nothing is left, and round-tripping them is where a database driver usually turns a typed empty into a plain NULL.
Intentionally invalid: four WKT strings that each break in a different way — a point with one ordinate, a line whose last vertex is ragged, a polygon missing a closing bracket, and a misspelled keyword. Good parsers report which line and which character failed.
Intentionally invalid: the five towns with their coordinates written latitude-first. RFC 7946 fixes the order as longitude then latitude, and this is the mistake that arrives via an EPSG-URN-ordered source such as the GML twin in the territory subcategory.
Intentionally invalid: Web Mercator metres inside a file that claims to be GeoJSON, with a legacy `crs` member as the only hint. RFC 7946 allows exactly one coordinate system, so this file is what a desktop GIS produces when someone exports a projected layer to GeoJSON without reprojecting it first.
Every required MBTiles table and metadata key, and not one tile row. This is what a failed or interrupted tile build actually produces, and it is the fixture that finds code which reports success because the file opened and the schema validated.
The same five towns as the territory GML twin, but declared with the CRS84 URN instead of the EPSG one — which flips the axis order to longitude first. The two files are otherwise identical in structure, so together they isolate axis-order handling from everything else.
GML 2.1 packed coordinates into a single `gml:coordinates` string whose decimal, coordinate and tuple separators are all declared as attributes and can be anything. GML 3 replaced it with `gml:posList`, but WFS 1.0 servers still emit this, and a parser that assumes the default separators mis-reads any file that changes them.
Intentionally invalid: a way referencing node -9 and a relation referencing way -999, neither of which is in the file. This is the normal state of a bounding-box extract, where objects are clipped at the boundary — so a reader has to decide between rejecting the file and building partial geometry, and must say which.
One variable that hides absent data three different ways at once: two _FillValue cells, one legacy missing_value cell and one raw NaN, with valid_min and valid_max also declared. Averaging the raw array without honouring all three gives roughly -60 K instead of a real mean.
An intentionally corrupt NetCDF file, cut to its first 512 bytes so the magic number and part of the header survive but the variable table and every data value do not. It is the fixture for the failure path where format detection succeeds and reading must not.
Single-precision FITS pixels including two NaNs, which is the only way the standard marks undefined data for floating BITPIX, plus one +Inf. Statistics computed without NaN-aware reductions come back as NaN for the entire frame.
Integer FITS images mark undefined pixels with the BLANK keyword, and BLANK is compared against the stored value before BZERO and BSCALE are applied. Scale first and the four undefined pixels turn into a perfectly plausible zero, which is the ordering bug this file exists to expose.
A completely valid FITS file consisting of one 2880-byte header block and no data unit, which the standard permits whenever NAXIS is 0. It separates readers that model the data array as optional from readers that treat 'no pixels' as corruption.
An intentionally corrupt FITS file whose header is complete and whose data unit is cut short, leaving a total length that is not a multiple of the mandatory 2880-byte block. A reader must report the short read rather than hand back a half-filled array padded with whatever it found.
Twelve datasets, one per numeric HDF5 type, each holding the extreme values of that type including the uint64 and int64 limits that do not survive a trip through a double. It is the fixture that exposes a reader which widens everything to float64 on the way in.
One array reachable under four names: itself, a hard link sharing its object address, a soft link resolved at access time, and a soft link pointing nowhere. A walker that counts names instead of object addresses reports four arrays and then crashes on the dangling one.
Five degenerate but entirely legal datasets — a rank-0 scalar, a zero-length vector, a (0, 5) array, a single-element vector and a NULL dataspace — plus an empty group. None of them is corrupt, and a reader that reports them as errors is the thing being tested.
An intentionally corrupt HDF5 file cut to 1024 bytes, so the 8-byte signature and superblock survive while the object headers and B-trees they point at do not. Format sniffing will say HDF5 and opening must fail loudly, which is exactly the split this fixture measures.
A 300-field structured array whose descriptor is too long for a version 1.0 header, forcing format version 2.0 and its four-byte header-length field. A hand-rolled parser that assumes the two-byte 1.0 field mis-locates the data section entirely.
Every structurally interesting float16 value in one array: one plus epsilon, the largest finite value, the smallest normal and subnormal, negative zero, infinity and a NaN. It is the compact half-precision counterpart to the float32 and float64 boundary fixtures.
A valid .npy file with a full header, a declared (0, 4) shape and a data section of zero bytes. It preserves the column count across an empty result, and it separates readers that model emptiness from readers that treat it as failure.
A rank-0 .npy holding a single double, whose header shape is the empty tuple rather than (1,). Indexing it with [0] raises rather than returning the value, so it separates parsers that model rank properly from parsers that assume at least one axis.
The sixteen structurally distinct float64 values a numeric pipeline has to survive, in binary form: both zeros, both subnormal limits, the smallest normal, epsilon, the largest finite value, both infinities, a quiet NaN and the 2^53 integer boundary. Round-tripping this array is the minimum bar for any float64 codec.
The same boundary values as strict RFC 8259 JSON, where non-finite numbers are null in the numeric field and text in the string field because the standard has no NaN or Infinity literal. It is the fixture for the encoder that emits bare NaN and produces JSON nothing else will parse.
The single-precision counterpart of the float64 boundary array, including the 2^24 integer limit where consecutive whole numbers stop being representable. Widening float32 to float64 and back must preserve every one of these bit patterns.
Six distinct NaN bit patterns — quiet, signalling, signed and payload-carrying — stored as float64. They are all NaN and none equals another, so any code that deduplicates, sorts or hashes them by value is doing something undefined and this array proves it.
A ten-step ladder from the smallest representable double up across the subnormal boundary into normal range, showing precision degrading to a single significant bit. Any pipeline running with flush-to-zero enabled turns the first eight entries into plain zeros without reporting anything.
The precision-loss cases as a two-column float64 array holding the original value beside its float32 round trip, both kept at double width so the difference itself is representable. Subtracting the columns gives the error directly without a second narrowing step.
Six large integers written both as JSON numbers and as strings, including the 2^53 boundary where consecutive integers stop being distinguishable in a double. A parser backed by doubles turns 9007199254740993 into 9007199254740992 and reports no error at all.
Sixteen doubles as a bare 128-byte block with no header, so byte order is knowledge the reader has to bring rather than something the file declares. It is one half of an endian pair that only a correct assumption tells apart.
The same sixteen doubles written in network byte order, so every eight-byte group is the mirror of the little-endian twin. Decoding it with the wrong assumption produces small plausible-looking numbers rather than an error, which is why this pair exists.
Nine laboratory results where only four are plain numbers: two are below the detection limit, one is above range, two are missing in different spellings, and one is a legitimate small negative near the blank. Coercing the censored strings to numbers or to NaN both bias the summary, and the file distinguishes every case explicitly.
The identical element stream with the 128-byte preamble and the DICM magic stripped, which is how DICOM often arrives out of a network transfer or a database blob column. It is not a conformant Part 10 file and its content is entirely recoverable, so a reader should fall back rather than reject.
An intentionally corrupt DICOM-shaped file whose header, meta group and every non-pixel element are valid, and whose PixelData element declares a length the file does not contain. A viewer must report the short read rather than render a partial image padded with whatever it found.
A CIF built entirely out of the constructs that break naive parsers: quoted values containing apostrophes and hashes, a semicolon-delimited multi-line text field, the distinct '?' and '.' markers, a standard uncertainty written as 1.2345(7), and a loop whose rows wrap across lines. Every one of them is legal CIF.
An intentionally corrupt molfile whose counts line declares twelve atoms while the atom block contains nine, so a parser reading by count consumes three bond lines as atoms. Everything else about the file is well formed, which is what makes the failure quiet.
Three synthetic protein sequences that begin with methionine and include the X, B and Z ambiguity codes, which are legal IUPAC residues rather than errors. A validator restricted to the twenty standard amino acids rejects all three files.
An intentionally corrupt FASTQ whose first five records are complete and whose sixth ends after the plus line, leaving no quality string. A four-line-block reader must report an incomplete final record rather than pairing the sequence with an empty quality string.
A valid Matrix Market file describing a 6x6 matrix with no stored entries, which is an all-zero matrix rather than an error. It separates readers that model an empty result from readers that treat a missing entry block as truncation.
An intentionally corrupt Matrix Market file whose banner and size line are perfectly valid and whose entry block stops seven lines short of the declared count. A reader that preallocates from the declared count and never checks ends up with seven silent zeros.
An intentionally invalid GitHub Actions workflow: well-formed YAML that breaks the workflow schema in four documented ways — no jobs mapping, a scalar `on`, a mapping `runs-on`, and a step carrying both uses and run. For testing that a validator rejects, and reports why.
An intentionally invalid GitLab CI config: valid YAML with a misspelled `stagess` key, a job naming an undeclared stage, a job with no script, and an `only:` given a bare scalar. For testing that a linter rejects it and names each fault.
An intentionally invalid CircleCI config: an unquoted `version: 2.10` that YAML loads as the float 2.1, a workflow referencing an undefined job, and a job with no execution environment. For testing that a validator rejects it and explains each fault.
An intentionally invalid Azure Pipelines file: valid YAML that mixes top-level steps with a stages block, depends on an undeclared stage, and gives `pool` a bare string. For testing that a validator rejects it and reports all three faults.
An intentionally invalid Jenkinsfile: an unclosed stage block so braces never balance, a steps block outside any stage, and a bare identifier where the agent directive needs any, none, or a block. For testing parser error recovery and reporting.
An intentionally invalid Kubernetes manifest: a removed apiVersion, a quoted string where replicas needs an integer, a selector that does not match the pod template, and containers as a mapping instead of a list. Four documented faults for a validator to report.
The shared topology plus one back edge, making it intentionally invalid as a DAG. The document publishes the cycle it contains, so a scheduler or graph validator can be tested on both detecting the cycle and naming it.
An intentionally invalid CWL document: a nonexistent cwlVersion, an unknown class, a step consuming an output no step produces, and outputs given as a bare string. Four documented faults for a CWL validator to report.
An intentionally invalid Terraform configuration: an unclosed resource block, a colon where HCL needs an equals sign, a reference to an undeclared resource, and a resource block missing its second label. Four documented faults for a parser to report.
An intentionally invalid HCL2 document: an unclosed block, a colon assignment, a half-quoted block label, and a heredoc whose terminator is misspelled so it swallows the remainder of the file. Four documented faults, each a distinct recovery test.
An intentionally invalid Compose file: services as a list, a service with both image and an empty build, an unquoted 8080:8080 port that YAML 1.1 reads as a base-60 integer, and a depends_on naming an undefined service.
An intentionally invalid Makefile whose recipe lines are indented with four spaces instead of the required TAB. This is the most common Makefile defect there is, and it is invisible in most editors — which is exactly why it belongs in a fixture set.
An intentionally invalid YAML file indented with real TAB characters, which the spec forbids for indentation. The final key shows the legal case — a tab inside a quoted scalar — so a parser can be checked for rejecting one without rejecting the other.
An intentionally invalid YAML file whose flow sequence is opened and never closed, so the parser consumes the rest of the document and fails at end of stream. A good error message names the opening bracket, not the last line, which is what this fixture measures.
PCM edge waveform 01 carrying controlled hard clipping for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-01.
PCM edge waveform 02 carrying a controlled silence window for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-02.
PCM edge waveform 03 carrying controlled hard clipping for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-03.
PCM edge waveform 04 carrying a controlled silence window for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-04.
PCM edge waveform 05 carrying controlled hard clipping for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-05.
PCM edge waveform 06 carrying a controlled silence window for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-06.
PCM edge waveform 07 carrying controlled hard clipping for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-07.
PCM edge waveform 08 carrying a controlled silence window for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-08.
PCM edge waveform 09 carrying controlled hard clipping for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-09.
PCM edge waveform 10 carrying a controlled silence window for edit-pipeline recovery checks. Stable P8 artifact p8-audio-edge-wav-10.
Download-only JSON control for video workflow 01; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-01-edge-case.
Download-only JSON control for video workflow 02; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-02-edge-case.
Download-only JSON control for video workflow 03; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-03-edge-case.
Download-only JSON control for video workflow 04; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-04-edge-case.
Download-only JSON control for video workflow 05; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-05-edge-case.
Download-only JSON control for video workflow 06; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-06-edge-case.
Download-only JSON control for video workflow 07; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-07-edge-case.
Download-only JSON control for video workflow 08; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-08-edge-case.
Download-only JSON control for video workflow 09; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-09-edge-case.
Download-only JSON control for video workflow 10; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-10-edge-case.
Download-only JSON control for video workflow 11; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-11-edge-case.
Download-only JSON control for video workflow 12; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-12-edge-case.
Download-only JSON control for video workflow 13; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-13-edge-case.
Download-only JSON control for video workflow 14; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-14-edge-case.
Download-only JSON control for video workflow 15; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-15-edge-case.
Download-only JSON control for video workflow 16; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-16-edge-case.
Download-only JSON control for video workflow 17; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-17-edge-case.
Download-only JSON control for video workflow 18; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-18-edge-case.
Download-only JSON control for video workflow 19; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-19-edge-case.
Download-only JSON control for video workflow 20; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-20-edge-case.
Download-only JSON control for video workflow 21; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-21-edge-case.
Download-only JSON control for video workflow 22; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-22-edge-case.
Download-only JSON control for video workflow 23; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-23-edge-case.
Download-only JSON control for video workflow 24; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-24-edge-case.
Download-only JSON control for video workflow 25; it removes the source timebase and publishes the only acceptable 12 fps fallback. Stable P8 artifact p8-video-kit-25-edge-case.
Download-only JSON failure contract 01 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-01.
Download-only JSON failure contract 02 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-02.
Download-only JSON failure contract 03 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-03.
Download-only JSON failure contract 04 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-04.
Download-only JSON failure contract 05 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-05.
Download-only JSON failure contract 06 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-06.
Download-only JSON failure contract 07 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-07.
Download-only JSON failure contract 08 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-08.
Download-only JSON failure contract 09 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-09.
Download-only JSON failure contract 10 declaring one timestamp gap and a report-and-preserve recovery policy. Stable P8 artifact p8-video-failure-json-10.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
