The same content exported across many formats and linked as a group, so you can convert one and diff against the expected twin.
A 1024×1024 fruit still life exported as PNG: one member of a conversion set that carries identical content across formats, so you can convert one and diff against the others.
A 1024×1024 fruit still life exported as JPG: one member of a conversion set that carries identical content across formats, so you can convert one and diff against the others.
A 1024×1024 fruit still life exported as WEBP: one member of a conversion set that carries identical content across formats, so you can convert one and diff against the others.
A 1024×1024 fruit still life exported as GIF: one member of a conversion set that carries identical content across formats, so you can convert one and diff against the others.
A 1024×1024 fruit still life exported as BMP: one member of a conversion set that carries identical content across formats, so you can convert one and diff against the others.
A 1024×1024 fruit still life exported as TIFF: one member of a conversion set that carries identical content across formats, so you can convert one and diff against the others.
A 1024×1024 fruit still life exported as AVIF: the modern-codec member of the conversion set.
A 1024×1024 fruit still life exported as HEIC: the HEIF/HEVC member of the conversion set, the format modern phones use for photos.
A 1024×1024 fruit still life exported as HEIF: the HEIF/HEVC member of the conversion set, the format modern phones use for photos.
A Windows ICO containing four square sizes (16/32/48/64 px) of a simple app glyph: the classic favicon/desktop-icon container. Handy for testing icon extraction and multi-size rendering.
A 12-frame animated PNG (APNG) of a rotating arc: a lossless, alpha-capable alternative to animated GIF. Useful for testing APNG support, frame extraction, and GIF↔APNG conversion.
A 256×256 fruit still-life image saved as uncompressed Truevision TGA: a format common in games and 3D texturing. For testing TGA decoders and conversion to modern formats.
A 256×256 fruit still-life image as binary Netpbm P6 (24-bit colour): the minimal, header-plus-raw-pixels family used across Unix imaging tools. For testing Netpbm parsers and conversion.
A 256×256 fruit still-life image as binary Netpbm P5 (8-bit greyscale): the minimal, header-plus-raw-pixels family used across Unix imaging tools. For testing Netpbm parsers and conversion.
A 256×256 fruit still-life image as binary Netpbm P4 (1-bit bitmap): the minimal, header-plus-raw-pixels family used across Unix imaging tools. For testing Netpbm parsers and conversion.
The same 512px source saved at JPEG quality 10: part of a q10/50/90 ladder for comparing compression artefacts at a glance.
The same 512px source saved at JPEG quality 50: part of a q10/50/90 ladder for comparing compression artefacts at a glance.
The same 512px source saved at JPEG quality 90: part of a q10/50/90 ladder for comparing compression artefacts at a glance.
A 16-bit (deep-colour) grayscale PNG holding a smooth 0–65535 gradient, for testing high-bit-depth support and spotting banding when a tool truncates to 8-bit.
The fruit still life converted to the CMYK (print) colour space and saved as a JPEG, for testing CMYK decoding and CMYK→RGB conversion. Some web viewers render CMYK JPEGs with a colour shift.
A generic sample brand logo as scalable vector graphics (a gradient mark plus a wordmark) for testing SVG rendering, rasterisation, and vector-to-raster conversion. Opens in the in-browser editor.
A single stroke-style UI icon (a document) as a 24×24 SVG: the kind of vector icon used in interfaces, for testing icon rendering, recolouring, and SVG-to-PNG conversion.
A bar chart drawn as vector SVG (axis, gridlines, labelled bars), the scalable counterpart to the raster chart images, for testing SVG chart rendering and vector conversion.
An animated loading spinner using SMIL (animateTransform): a self-contained animated SVG for testing whether a renderer or converter handles SVG animation, and how it rasterises an animated frame.
A flat vector landscape (gradient sky, sun, layered hills, and trees built from bezier paths), a richer SVG for testing gradient and path rendering, thumbnailing, and vector conversion.
A linear 16-bit greyscale TIFF ramp (0–65535). Not a PQ HDR master, for testing high bit-depth TIFF loaders and 16→8 truncation.
8-bit PNG twin of the linear 16-bit greyscale ramp. Compare banding after truncation.
JPEG with EXIF Orientation=1 (normal). Pixels are upright: viewers/tools should apply the tagged transform. SAMPLE fixture.
JPEG with EXIF Orientation=3 (rotate-180). Pixels are upright: viewers/tools should apply the tagged transform. SAMPLE fixture.
JPEG with EXIF Orientation=6 (rotate-90-cw). Pixels are upright: viewers/tools should apply the tagged transform. SAMPLE fixture.
JPEG with EXIF Orientation=8 (rotate-90-ccw). Pixels are upright: viewers/tools should apply the tagged transform. SAMPLE fixture.
JPEG with EXIF Orientation=2 (flip-h). Pixels are upright: viewers/tools should apply the tagged transform. SAMPLE fixture.
JPEG with EXIF Orientation=4 (flip-v). Pixels are upright: viewers/tools should apply the tagged transform. SAMPLE fixture.
JPEG with less-common EXIF Orientation=5 (transpose) for exhaustive orientation-handler coverage.
JPEG with less-common EXIF Orientation=7 (transverse) for exhaustive orientation-handler coverage.
Three-page TIFF of synthetic scenes: fixture for multipage TIFF loaders and page extractors.
Single-page TIFF of the same scene as page 1 of the multipage twin.
RGBA sprite sheet (4×1 cells of 64px) with numbered frames for atlas / CSS-sprite tools.
RGBA sprite sheet (3×2 cells of 64px) with numbered frames for atlas / CSS-sprite tools.
RGBA sprite sheet (2×2 cells of 64px) with numbered frames for atlas / CSS-sprite tools.
Synthetic 16×16 favicon-size mark (not a real brand) for favicon pipeline / resize tests.
Synthetic 32×32 favicon-size mark (not a real brand) for favicon pipeline / resize tests.
Synthetic 48×48 favicon-size mark (not a real brand) for favicon pipeline / resize tests.
Synthetic 64×64 favicon-size mark (not a real brand) for favicon pipeline / resize tests.
Windows ICO containing 16/32/48 favicon sizes of the synthetic mark, for ICO parsers and extractors.
Two-page TIFF companion for multipage loader edge cases.
Same fruit scene encoded as png: rung on the Wave E codec ladder for quality / convert comparisons.
Same fruit scene encoded as q20: rung on the Wave E codec ladder for quality / convert comparisons.
Same fruit scene encoded as q50: rung on the Wave E codec ladder for quality / convert comparisons.
Same fruit scene encoded as q80: rung on the Wave E codec ladder for quality / convert comparisons.
Same fruit scene encoded as webp: rung on the Wave E codec ladder for quality / convert comparisons.
Same mug scene encoded as png: rung on the Wave E codec ladder for quality / convert comparisons.
Same mug scene encoded as q20: rung on the Wave E codec ladder for quality / convert comparisons.
Same mug scene encoded as q50: rung on the Wave E codec ladder for quality / convert comparisons.
Same mug scene encoded as q80: rung on the Wave E codec ladder for quality / convert comparisons.
Same mug scene encoded as webp: rung on the Wave E codec ladder for quality / convert comparisons.
Same blocks scene encoded as png: rung on the Wave E codec ladder for quality / convert comparisons.
Same blocks scene encoded as q20: rung on the Wave E codec ladder for quality / convert comparisons.
Same blocks scene encoded as q50: rung on the Wave E codec ladder for quality / convert comparisons.
Same blocks scene encoded as q80: rung on the Wave E codec ladder for quality / convert comparisons.
Same blocks scene encoded as webp: rung on the Wave E codec ladder for quality / convert comparisons.
High-quality WebP of the fruit scene, near-lossless rung of the codec ladder.
64×64 linear 16-bit greyscale TIFF with deflate: Wave H depth for high bit-depth loaders.
LZW twin of the Wave H linear 16-bit greyscale TIFF.
A deterministic PNG with known text chunks and an embedded sRGB ICC profile, paired with a pixel-identical stripped control for extraction and privacy-tool tests.
The pixel-identical PNG control with text and ICC chunks removed, for proving that a scrubber changes metadata without changing decoded RGB values.
A losslessly compressed TIFF carrying known camera/software tags plus XMP and IPTC payloads, paired with an exactly decoded stripped image.
The same losslessly compressed TIFF pixels with EXIF-style, XMP and IPTC metadata absent, providing a ground-truth scrubber control.
A pure 440 Hz sine tone stored as AIFF: Apple's big-endian 16-bit PCM container, 3 seconds, 44.1 kHz mono. A clean reference for testing AIFF decoders and WAV↔AIFF conversion.
A pure 440 Hz sine tone stored as a Sun/NeXT AU file, big-endian 16-bit PCM, 3 seconds, 44.1 kHz mono. A compact reference for AU decoding and format conversion.
A pure 1 kHz sine tone stored as AIFF: Apple's big-endian 16-bit PCM container, 3 seconds, 44.1 kHz mono. A clean reference for testing AIFF decoders and WAV↔AIFF conversion.
A pure 1 kHz sine tone stored as a Sun/NeXT AU file, big-endian 16-bit PCM, 3 seconds, 44.1 kHz mono. A compact reference for AU decoding and format conversion.
The lossless PCM WAV source for the audio conversion set: the same 3-second tone every other codec in this group is encoded from. Use it as the reference when diffing encoders.
The source clip as constant-bitrate MP3 (LAME, 192 kbps): the most universally supported lossy audio format. For testing MP3 decoders, players, and conversion.
The same clip as variable-bitrate MP3 (LAME V2), for testing VBR handling, seeking, and duration estimation against the CBR twin.
The clip as FLAC: free lossless audio compression. Byte-for-byte recoverable to the source PCM; for testing lossless decoders and conversion.
The clip as Ogg Vorbis: a royalty-free lossy codec. Browser-playable; for testing Vorbis decoding and Ogg conversion.
The clip as Opus: the modern low-latency codec used by WebRTC and streaming. Browser-playable; for testing Opus decoding and conversion.
The clip as raw AAC in an ADTS stream: the codec behind most streaming and mobile audio. For testing AAC decoders and remux into MP4.
The clip as AAC in an MP4/M4A container (faststart): Apple's default audio container. For testing M4A parsing and MP4 audio conversion.
The clip as Apple Lossless (ALAC) in an M4A container: lossless, unlike the AAC M4A twin. For testing ALAC decoding and lossless conversion.
The clip as Windows Media Audio (WMA v2) in an ASF container: Microsoft's lossy codec. For testing WMA decoding and conversion to open formats.
The clip as AC-3 (Dolby Digital): the multichannel codec used in DVD/broadcast. Rendered here in stereo; for testing AC-3 decoding and conversion.
The clip as an M4R iPhone ringtone: AAC in an MP4 container with the ringtone extension. For testing that a converter maps M4R↔M4A correctly.
The clip resampled to 8 kHz mono and encoded as AMR narrowband: the telephony/voice-note codec. For testing AMR decoding and speech-codec conversion.
A 1 kHz sine tone sampled at 8000 Hz: part of a sample-rate ladder (8/16/44.1/48/96 kHz) of the identical tone, for testing resampling, sample-rate detection, and aliasing.
A 1 kHz sine tone sampled at 16000 Hz: part of a sample-rate ladder (8/16/44.1/48/96 kHz) of the identical tone, for testing resampling, sample-rate detection, and aliasing.
A 1 kHz sine tone sampled at 44100 Hz: part of a sample-rate ladder (8/16/44.1/48/96 kHz) of the identical tone, for testing resampling, sample-rate detection, and aliasing.
A 1 kHz sine tone sampled at 48000 Hz: part of a sample-rate ladder (8/16/44.1/48/96 kHz) of the identical tone, for testing resampling, sample-rate detection, and aliasing.
A 1 kHz sine tone sampled at 96000 Hz: part of a sample-rate ladder (8/16/44.1/48/96 kHz) of the identical tone, for testing resampling, sample-rate detection, and aliasing.
A 440 Hz sine tone stored as 8-bit PCM: part of a bit-depth ladder (8/16/24-bit) of the identical tone, for testing bit-depth conversion, dithering, and quantisation-noise handling.
A 440 Hz sine tone stored as 16-bit PCM: part of a bit-depth ladder (8/16/24-bit) of the identical tone, for testing bit-depth conversion, dithering, and quantisation-noise handling.
A 440 Hz sine tone stored as 24-bit PCM: part of a bit-depth ladder (8/16/24-bit) of the identical tone, for testing bit-depth conversion, dithering, and quantisation-noise handling.
An MP3 with a full set of ID3v2.3 tags (title, artist, album, date, genre, comment) over a synthetic C-major melody. A fixture for testing tag readers, metadata editors, and music-library importers.
Mono 440 Hz twin. Pair with the stereo file for channel-count / downmix tests.
Stereo twin of the 440 Hz tone (L=mono, R=phase-shifted) for stereo↔mono conversion tests.
Mono 523 Hz twin. Pair with the stereo file for channel-count / downmix tests.
Stereo twin of the 523 Hz tone (L=mono, R=phase-shifted) for stereo↔mono conversion tests.
Mono 659 Hz twin. Pair with the stereo file for channel-count / downmix tests.
Stereo twin of the 659 Hz tone (L=mono, R=phase-shifted) for stereo↔mono conversion tests.
Mono 784 Hz twin. Pair with the stereo file for channel-count / downmix tests.
Stereo twin of the 784 Hz tone (L=mono, R=phase-shifted) for stereo↔mono conversion tests.
Same 440 Hz tone rendered at 8000 Hz sample rate: twin in the 8k/16k/44.1k set.
Same 440 Hz tone rendered at 16000 Hz sample rate: twin in the 8k/16k/44.1k set.
Same 440 Hz tone rendered at 44100 Hz sample rate: twin in the 8k/16k/44.1k set.
880 Hz tone at 8000 Hz: second ladder for resampling QA.
880 Hz tone at 16000 Hz: second ladder for resampling QA.
880 Hz tone at 44100 Hz: second ladder for resampling QA.
An MP3 with deterministic ID3v2.3 text frames and embedded PNG cover art wrapped around unchanged MPEG audio frames.
The same MPEG audio frames with leading and trailing ID3 metadata removed, for checking metadata scrubbing without an audio transcode.
A FLAC whose STREAMINFO and audio frames are accompanied by known Vorbis comments and a 32-pixel PNG front cover.
The matching FLAC reduced to STREAMINFO and the exact same audio frames, so metadata-removal tests can compare compressed essence byte for byte.
Real DTS Coherent Acoustics audio payload encoded from the same deterministic 0.7-second mono reference tone for legacy import coverage. Stable P8 artifact p8-convert-legacy-dts.
Real Yamaha SMAF audio payload encoded from the same deterministic 0.7-second mono reference tone for legacy import coverage. Stable P8 artifact p8-convert-legacy-mmf.
A Word document with styled headings, bold/italic runs, a table, and an embedded image, for testing DOCX parsers and converters against a rich document.
A minimal Word document of plain paragraphs with no styling: the simplest valid DOCX for baseline parser testing.
A two-sheet workbook where a Summary sheet references a Data sheet with SUM and arithmetic formulas, for testing spreadsheet parsers, formula evaluation, and converters.
A Rich Text Format document exercising bold, italic, underline, colour, headings, and a bullet list: all as plain control words. For testing RTF parsers, text extraction, and RTF→DOCX/PDF conversion.
The simplest possible RTF: one monospace font and a couple of paragraphs, no styling. A minimal baseline for RTF parsers and conversion tools.
An OpenDocument Text file carrying the same content as the formatted DOCX, styled heading, bold/italic runs, and a table. The open twin in a DOCX↔ODT conversion set.
An OpenDocument Spreadsheet with the same tabular data as the plain XLSX and legacy XLS: a member of an XLSX↔ODS↔XLS conversion set for spreadsheet importers.
A legacy Excel 97–2003 (.xls / BIFF8) workbook holding the same tabular data as the plain XLSX and ODS, for testing legacy-format readers and XLS↔XLSX conversion.
A three-slide OpenDocument Presentation with titles and body text, for testing ODP readers and slide converters. Original content, free to use.
The formatted Word document saved as legacy binary .doc (Word 97-2003, OLE compound file) via LibreOffice. For testing legacy-Office parsers and DOC→DOCX conversion.
A pitch-deck slide set saved as legacy binary .ppt (PowerPoint 97-2003, OLE compound file) via LibreOffice. For testing legacy-Office parsers and PPT→PPTX conversion.
A SubRip (SRT) subtitle track with three timed cues: the most common subtitle format. Paired with the WebVTT twin for testing subtitle parsers and SRT↔VTT conversion.
A WebVTT subtitle track with three timed cues: the HTML5 <track> subtitle format. Paired with the SRT twin for testing subtitle parsers and VTT↔SRT conversion.
A workbook with a data table plus a native bar chart and a line chart bound to the cells, for testing whether spreadsheet parsers and XLSX-to-PDF converters preserve and render embedded charts.
A dashboard sheet exercising the features importers miss: a merged title cell, a three-colour conditional-formatting scale, a data-validation dropdown, cell borders, and frozen panes.
A four-slide presentation where every slide carries speaker notes in the notes pane, for testing notes extraction and whether converters preserve the notes alongside the slides.
A Word document with real tracked changes (insertions and deletions attributed to two reviewers with timestamps) for testing how tools read, accept, reject, or preserve revisions.
A Word document with two anchored reviewer comments, for testing comment extraction and whether converters preserve or drop review annotations.
A small LaTeX article source with an abstract, a numbered equation (the Nyquist criterion), and a table, for testing LaTeX editors, syntax highlighters, and TeX-to-PDF pipelines.
An AsciiDoc getting-started guide with source blocks, an admonition, and a table, for testing AsciiDoc renderers (Asciidoctor), editors, and conversion to HTML/PDF.
A reStructuredText document with directives, a code block, a note admonition, and a table, for testing docutils/Sphinx rendering, reST parsers, and editors.
An HL7 v2.5 ADT^A01 patient-admission message: pipe/caret-delimited segments (MSH, EVN, PID, PV1, allergies, diagnosis). A fixture for testing healthcare integration engines and HL7 parsers. The patient is fictional.
An ANSI X12 850 purchase order: ISA/GS/ST envelope with BEG, N1, and PO1 line items. A fixture for testing EDI parsers and translators. Paired with the 810 invoice for the same order.
An ANSI X12 810 invoice that references the 850 purchase order: ISA/GS/ST envelope with BIG, IT1 line items, and a total. The invoice twin of the purchase order, for testing EDI document flows.
An Advanced SubStation Alpha (.ass) subtitle with a styles section and three timed Dialogue events (the styled format libass renders) carrying the same captions as the SRT/VTT twins.
A SubStation Alpha (.ssa) subtitle (the predecessor of ASS) with a V4 styles section and timed Dialogue events, carrying the same captions, for testing SSA parsers and SSA-to-ASS upgrades.
A YouTube SBV caption file (start,end timestamp lines followed by caption text) carrying the same three captions, for testing SBV parsers and YouTube caption import.
A TTML (Timed Text Markup Language / DFXP) caption document (timed XML paragraphs with a styling region) carrying the same captions, for testing XML caption parsers and IMSC players.
A three-page PDF mixing US Letter, A4, and landscape Letter page boxes, for testing viewers and converters that assume uniform page size.
Short SAMPLE FAQ markdown (faq-downloads) for docs renderers and SEO snippets.
Short SAMPLE FAQ markdown (faq-licensing) for docs renderers and SEO snippets.
Short SAMPLE FAQ markdown (faq-security) for docs renderers and SEO snippets.
Short SAMPLE FAQ markdown (faq-csv-edges) for docs renderers and SEO snippets.
Short SAMPLE FAQ markdown (faq-i18n) for docs renderers and SEO snippets.
Short SAMPLE FAQ markdown (faq-api-errors) for docs renderers and SEO snippets.
Fictional SAMPLE legal/policy markdown (cookie-notice-sample), not legal advice.
Fictional SAMPLE legal/policy markdown (terms-snippet-sample), not legal advice.
Fictional SAMPLE legal/policy markdown (accessibility-statement), not legal advice.
Fictional SAMPLE legal/policy markdown (retention-policy-sample), not legal advice.
Fictional SAMPLE legal/policy markdown (incident-response-outline), not legal advice.
Fictional SAMPLE legal/policy markdown (dpa-definitions-sample), not legal advice.
A one-page PDF with a known Info dictionary and XMP metadata stream while its page-content stream remains identical to the stripped twin.
The same one-page PDF content stream with the Info dictionary and XMP stream omitted, for metadata redaction and document-ingestion tests.
A valid DOCX package with fixed core properties and two custom properties surrounding an unchanged word/document.xml part.
The same DOCX document part without core or custom property parts, suitable for checking OOXML metadata removal without content loss.
UBL 2.1 invoice XML for Alder Table Bistro. OASIS UBL 2.1 Invoice for INV-BST-5001 with 3 InvoiceLine elements, a TaxTotal of 10.38 on a taxable amount of 207.60, and a PayableAmount of 217.98 CAD. OrderReference names PO-BST-1001 and DespatchDocumentReference names GRN-BST-2001, both of which exist in this folder.
UBL 2.1 credit note XML for Alder Table Bistro. OASIS UBL 2.1 CreditNote for CN-BST-7002 with type code 381, a BillingReference to invoice INV-BST-5004 dated 2026-08-28, one CreditNoteLine of 5 l and a PayableAmount of 40.90 CAD. It carries the same over-credit as credit-note.pdf: 2 units more than GRN-BST-2004 records returned.
Factur-X CII invoice XML for Alder Table Bistro. UN/CEFACT Cross Industry Invoice for INV-BST-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 10.38 and a DuePayableAmount of 217.98 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
Factur-X hybrid invoice PDF for Alder Table Bistro. Invoice INV-BST-5001 rendered for a person and attached as machine-readable XML for a system. The embedded file is named factur-x.xml, is referenced from both the EmbeddedFiles name tree and the document-level AF array with an AFRelationship of Data, and is byte-identical to invoice-facturx-cii.xml. The visible page and the XML agree: net 207.60, GST 10.38, 217.98 CAD due. This is the only file in the set that carries its data twice in one container.
ANSI X12 850 purchase order for Alder Table Bistro. Version 004010 transaction set 850 for PO-BST-1002, control number 850002. 3 PO1 segments carry quantity, X12 unit code, unit price, the supplier item code (VP) and the buyer item code (BP); CTT declares 3 line items and SE declares 14 segments, which is the number actually present between ST and SE inclusive.
ANSI X12 856 despatch advice for Alder Table Bistro. Version 004010 transaction set 856 for supplier delivery note DN-BST-3002 against PO-BST-1002, control number 856002. The shipment, order and item hierarchy uses HL segments, and the SN1 quantities are the quantities actually delivered, so line 2 reports 16 where the 850 ordered 20.
ANSI X12 810 invoice for Alder Table Bistro. Version 004010 transaction set 810 for invoice INV-BST-5002, control number 810002. 3 IT1 segments, a TXI segment stating GST of 15.69, and a TDS segment of 32953 in implied-decimal cents, which is 329.53 CAD. SE declares 13 segments and 13 are present.
ANSI X12 810 invoice with a wrong SE segment count for Alder Table Bistro. Identical to edi-810-invoice.edi except for one element: SE declares 11 segments where 13 are present between ST and SE inclusive. The ISA, GS, GE and IEA control numbers, every data segment and the TDS total of 32953 are unchanged, so a parser that checks only syntax accepts the file and only a parser that recounts segments rejects it.
UBL 2.1 invoice XML for Juniper Corner Cafe. OASIS UBL 2.1 Invoice for INV-CAF-5001 with 3 InvoiceLine elements, a TaxTotal of 16.53 on a taxable amount of 330.69, and a PayableAmount of 347.22 CAD. OrderReference names PO-CAF-1001 and DespatchDocumentReference names GRN-CAF-2001, both of which exist in this folder.
UBL 2.1 credit note XML for Juniper Corner Cafe. OASIS UBL 2.1 CreditNote for CN-CAF-7002 with type code 381, a BillingReference to invoice INV-CAF-5004 dated 2026-08-28, one CreditNoteLine of 5 each and a PayableAmount of 7.98 CAD. It carries the same over-credit as credit-note.pdf: 2 units more than GRN-CAF-2004 records returned.
Factur-X CII invoice XML for Juniper Corner Cafe. UN/CEFACT Cross Industry Invoice for INV-CAF-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 16.53 and a DuePayableAmount of 347.22 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
Factur-X hybrid invoice PDF for Juniper Corner Cafe. Invoice INV-CAF-5001 rendered for a person and attached as machine-readable XML for a system. The embedded file is named factur-x.xml, is referenced from both the EmbeddedFiles name tree and the document-level AF array with an AFRelationship of Data, and is byte-identical to invoice-facturx-cii.xml. The visible page and the XML agree: net 330.69, GST 16.53, 347.22 CAD due. This is the only file in the set that carries its data twice in one container.
ANSI X12 850 purchase order for Juniper Corner Cafe. Version 004010 transaction set 850 for PO-CAF-1002, control number 850002. 3 PO1 segments carry quantity, X12 unit code, unit price, the supplier item code (VP) and the buyer item code (BP); CTT declares 3 line items and SE declares 14 segments, which is the number actually present between ST and SE inclusive.
ANSI X12 856 despatch advice for Juniper Corner Cafe. Version 004010 transaction set 856 for supplier delivery note DN-CAF-3002 against PO-CAF-1002, control number 856002. The shipment, order and item hierarchy uses HL segments, and the SN1 quantities are the quantities actually delivered, so line 2 reports 17 where the 850 ordered 21.
ANSI X12 810 invoice for Juniper Corner Cafe. Version 004010 transaction set 810 for invoice INV-CAF-5002, control number 810002. 3 IT1 segments, a TXI segment stating GST of 16.61, and a TDS segment of 34883 in implied-decimal cents, which is 348.83 CAD. SE declares 13 segments and 13 are present.
ANSI X12 810 invoice with a wrong SE segment count for Juniper Corner Cafe. Identical to edi-810-invoice.edi except for one element: SE declares 11 segments where 13 are present between ST and SE inclusive. The ISA, GS, GE and IEA control numbers, every data segment and the TDS total of 34883 are unchanged, so a parser that checks only syntax accepts the file and only a parser that recounts segments rejects it.
UBL 2.1 invoice XML for Copper Oven Bakery. OASIS UBL 2.1 Invoice for INV-BAK-5001 with 3 InvoiceLine elements, a TaxTotal of 8.27 on a taxable amount of 165.41, and a PayableAmount of 173.68 CAD. OrderReference names PO-BAK-1001 and DespatchDocumentReference names GRN-BAK-2001, both of which exist in this folder.
UBL 2.1 credit note XML for Copper Oven Bakery. OASIS UBL 2.1 CreditNote for CN-BAK-7002 with type code 381, a BillingReference to invoice INV-BAK-5004 dated 2026-08-28, one CreditNoteLine of 5 kg and a PayableAmount of 25.94 CAD. It carries the same over-credit as credit-note.pdf: 2 units more than GRN-BAK-2004 records returned.
Factur-X CII invoice XML for Copper Oven Bakery. UN/CEFACT Cross Industry Invoice for INV-BAK-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 8.27 and a DuePayableAmount of 173.68 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
Factur-X hybrid invoice PDF for Copper Oven Bakery. Invoice INV-BAK-5001 rendered for a person and attached as machine-readable XML for a system. The embedded file is named factur-x.xml, is referenced from both the EmbeddedFiles name tree and the document-level AF array with an AFRelationship of Data, and is byte-identical to invoice-facturx-cii.xml. The visible page and the XML agree: net 165.41, GST 8.27, 173.68 CAD due. This is the only file in the set that carries its data twice in one container.
ANSI X12 850 purchase order for Copper Oven Bakery. Version 004010 transaction set 850 for PO-BAK-1002, control number 850002. 3 PO1 segments carry quantity, X12 unit code, unit price, the supplier item code (VP) and the buyer item code (BP); CTT declares 3 line items and SE declares 14 segments, which is the number actually present between ST and SE inclusive.
ANSI X12 856 despatch advice for Copper Oven Bakery. Version 004010 transaction set 856 for supplier delivery note DN-BAK-3002 against PO-BAK-1002, control number 856002. The shipment, order and item hierarchy uses HL segments, and the SN1 quantities are the quantities actually delivered, so line 2 reports 18 where the 850 ordered 22.
ANSI X12 810 invoice for Copper Oven Bakery. Version 004010 transaction set 810 for invoice INV-BAK-5002, control number 810002. 3 IT1 segments, a TXI segment stating GST of 13.79, and a TDS segment of 28965 in implied-decimal cents, which is 289.65 CAD. SE declares 13 segments and 13 are present.
ANSI X12 810 invoice with a wrong SE segment count for Copper Oven Bakery. Identical to edi-810-invoice.edi except for one element: SE declares 11 segments where 13 are present between ST and SE inclusive. The ISA, GS, GE and IEA control numbers, every data segment and the TDS total of 28965 are unchanged, so a parser that checks only syntax accepts the file and only a parser that recounts segments rejects it.
UBL 2.1 invoice XML for Ember Lane Pizza. OASIS UBL 2.1 Invoice for INV-PIZ-5001 with 3 InvoiceLine elements, a TaxTotal of 12.19 on a taxable amount of 243.81, and a PayableAmount of 256.00 CAD. OrderReference names PO-PIZ-1001 and DespatchDocumentReference names GRN-PIZ-2001, both of which exist in this folder.
UBL 2.1 credit note XML for Ember Lane Pizza. OASIS UBL 2.1 CreditNote for CN-PIZ-7002 with type code 381, a BillingReference to invoice INV-PIZ-5004 dated 2026-08-28, one CreditNoteLine of 5 each and a PayableAmount of 2.73 CAD. It carries the same over-credit as credit-note.pdf: 2 units more than GRN-PIZ-2004 records returned.
Factur-X CII invoice XML for Ember Lane Pizza. UN/CEFACT Cross Industry Invoice for INV-PIZ-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 12.19 and a DuePayableAmount of 256.00 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
Factur-X hybrid invoice PDF for Ember Lane Pizza. Invoice INV-PIZ-5001 rendered for a person and attached as machine-readable XML for a system. The embedded file is named factur-x.xml, is referenced from both the EmbeddedFiles name tree and the document-level AF array with an AFRelationship of Data, and is byte-identical to invoice-facturx-cii.xml. The visible page and the XML agree: net 243.81, GST 12.19, 256.00 CAD due. This is the only file in the set that carries its data twice in one container.
ANSI X12 850 purchase order for Ember Lane Pizza. Version 004010 transaction set 850 for PO-PIZ-1002, control number 850002. 3 PO1 segments carry quantity, X12 unit code, unit price, the supplier item code (VP) and the buyer item code (BP); CTT declares 3 line items and SE declares 14 segments, which is the number actually present between ST and SE inclusive.
ANSI X12 856 despatch advice for Ember Lane Pizza. Version 004010 transaction set 856 for supplier delivery note DN-PIZ-3002 against PO-PIZ-1002, control number 856002. The shipment, order and item hierarchy uses HL segments, and the SN1 quantities are the quantities actually delivered, so line 2 reports 19 where the 850 ordered 23.
ANSI X12 810 invoice for Ember Lane Pizza. Version 004010 transaction set 810 for invoice INV-PIZ-5002, control number 810002. 3 IT1 segments, a TXI segment stating GST of 22.33, and a TDS segment of 46893 in implied-decimal cents, which is 468.93 CAD. SE declares 13 segments and 13 are present.
ANSI X12 810 invoice with a wrong SE segment count for Ember Lane Pizza. Identical to edi-810-invoice.edi except for one element: SE declares 11 segments where 13 are present between ST and SE inclusive. The ISA, GS, GE and IEA control numbers, every data segment and the TDS total of 46893 are unchanged, so a parser that checks only syntax accepts the file and only a parser that recounts segments rejects it.
UBL 2.1 invoice XML for Cedar Street Tacos. OASIS UBL 2.1 Invoice for INV-TRK-5001 with 3 InvoiceLine elements, a TaxTotal of 9.38 on a taxable amount of 187.70, and a PayableAmount of 197.08 CAD. OrderReference names PO-TRK-1001 and DespatchDocumentReference names GRN-TRK-2001, both of which exist in this folder.
UBL 2.1 credit note XML for Cedar Street Tacos. OASIS UBL 2.1 CreditNote for CN-TRK-7002 with type code 381, a BillingReference to invoice INV-TRK-5004 dated 2026-08-28, one CreditNoteLine of 5 each and a PayableAmount of 1.10 CAD. It carries the same over-credit as credit-note.pdf: 2 units more than GRN-TRK-2004 records returned.
Factur-X CII invoice XML for Cedar Street Tacos. UN/CEFACT Cross Industry Invoice for INV-TRK-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 9.38 and a DuePayableAmount of 197.08 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
Factur-X hybrid invoice PDF for Cedar Street Tacos. Invoice INV-TRK-5001 rendered for a person and attached as machine-readable XML for a system. The embedded file is named factur-x.xml, is referenced from both the EmbeddedFiles name tree and the document-level AF array with an AFRelationship of Data, and is byte-identical to invoice-facturx-cii.xml. The visible page and the XML agree: net 187.70, GST 9.38, 197.08 CAD due. This is the only file in the set that carries its data twice in one container.
ANSI X12 850 purchase order for Cedar Street Tacos. Version 004010 transaction set 850 for PO-TRK-1002, control number 850002. 3 PO1 segments carry quantity, X12 unit code, unit price, the supplier item code (VP) and the buyer item code (BP); CTT declares 3 line items and SE declares 14 segments, which is the number actually present between ST and SE inclusive.
ANSI X12 856 despatch advice for Cedar Street Tacos. Version 004010 transaction set 856 for supplier delivery note DN-TRK-3002 against PO-TRK-1002, control number 856002. The shipment, order and item hierarchy uses HL segments, and the SN1 quantities are the quantities actually delivered, so line 2 reports 20 where the 850 ordered 24.
ANSI X12 810 invoice for Cedar Street Tacos. Version 004010 transaction set 810 for invoice INV-TRK-5002, control number 810002. 3 IT1 segments, a TXI segment stating GST of 4.97, and a TDS segment of 10433 in implied-decimal cents, which is 104.33 CAD. SE declares 13 segments and 13 are present.
ANSI X12 810 invoice with a wrong SE segment count for Cedar Street Tacos. Identical to edi-810-invoice.edi except for one element: SE declares 11 segments where 13 are present between ST and SE inclusive. The ISA, GS, GE and IEA control numbers, every data segment and the TDS total of 10433 are unchanged, so a parser that checks only syntax accepts the file and only a parser that recounts segments rejects it.
UBL 2.1 invoice XML for Willow Event Kitchen. OASIS UBL 2.1 Invoice for INV-CAT-5001 with 3 InvoiceLine elements, a TaxTotal of 14.79 on a taxable amount of 295.84, and a PayableAmount of 310.63 CAD. OrderReference names PO-CAT-1001 and DespatchDocumentReference names GRN-CAT-2001, both of which exist in this folder.
UBL 2.1 credit note XML for Willow Event Kitchen. OASIS UBL 2.1 CreditNote for CN-CAT-7002 with type code 381, a BillingReference to invoice INV-CAT-5004 dated 2026-08-28, one CreditNoteLine of 5 each and a PayableAmount of 5.99 CAD. It carries the same over-credit as credit-note.pdf: 2 units more than GRN-CAT-2004 records returned.
Factur-X CII invoice XML for Willow Event Kitchen. UN/CEFACT Cross Industry Invoice for INV-CAT-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 14.79 and a DuePayableAmount of 310.63 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
Factur-X hybrid invoice PDF for Willow Event Kitchen. Invoice INV-CAT-5001 rendered for a person and attached as machine-readable XML for a system. The embedded file is named factur-x.xml, is referenced from both the EmbeddedFiles name tree and the document-level AF array with an AFRelationship of Data, and is byte-identical to invoice-facturx-cii.xml. The visible page and the XML agree: net 295.84, GST 14.79, 310.63 CAD due. This is the only file in the set that carries its data twice in one container.
ANSI X12 850 purchase order for Willow Event Kitchen. Version 004010 transaction set 850 for PO-CAT-1002, control number 850002. 3 PO1 segments carry quantity, X12 unit code, unit price, the supplier item code (VP) and the buyer item code (BP); CTT declares 3 line items and SE declares 14 segments, which is the number actually present between ST and SE inclusive.
ANSI X12 856 despatch advice for Willow Event Kitchen. Version 004010 transaction set 856 for supplier delivery note DN-CAT-3002 against PO-CAT-1002, control number 856002. The shipment, order and item hierarchy uses HL segments, and the SN1 quantities are the quantities actually delivered, so line 2 reports 21 where the 850 ordered 25.
ANSI X12 810 invoice for Willow Event Kitchen. Version 004010 transaction set 810 for invoice INV-CAT-5002, control number 810002. 3 IT1 segments, a TXI segment stating GST of 9.92, and a TDS segment of 20813 in implied-decimal cents, which is 208.13 CAD. SE declares 13 segments and 13 are present.
ANSI X12 810 invoice with a wrong SE segment count for Willow Event Kitchen. Identical to edi-810-invoice.edi except for one element: SE declares 11 segments where 13 are present between ST and SE inclusive. The ISA, GS, GE and IEA control numbers, every data segment and the TDS total of 20813 are unchanged, so a parser that checks only syntax accepts the file and only a parser that recounts segments rejects it.
UBL 2.1 invoice XML for Harbour Kitchen Group. OASIS UBL 2.1 Invoice for INV-GRP-5001 with 3 InvoiceLine elements, a TaxTotal of 13.10 on a taxable amount of 261.93, and a PayableAmount of 275.03 CAD. OrderReference names PO-GRP-1001 and DespatchDocumentReference names GRN-GRP-2001, both of which exist in this folder.
UBL 2.1 credit note XML for Harbour Kitchen Group. OASIS UBL 2.1 CreditNote for CN-GRP-7002 with type code 381, a BillingReference to invoice INV-GRP-5004 dated 2026-08-28, one CreditNoteLine of 5 l and a PayableAmount of 9.98 CAD. It carries the same over-credit as credit-note.pdf: 2 units more than GRN-GRP-2004 records returned.
Factur-X CII invoice XML for Harbour Kitchen Group. UN/CEFACT Cross Industry Invoice for INV-GRP-5001 at the Factur-X BASIC guideline, with 3 trade line items, a TaxTotalAmount of 13.10 and a DuePayableAmount of 275.03 CAD. These bytes are the exact bytes embedded as factur-x.xml inside invoice-facturx.pdf.
Factur-X hybrid invoice PDF for Harbour Kitchen Group. Invoice INV-GRP-5001 rendered for a person and attached as machine-readable XML for a system. The embedded file is named factur-x.xml, is referenced from both the EmbeddedFiles name tree and the document-level AF array with an AFRelationship of Data, and is byte-identical to invoice-facturx-cii.xml. The visible page and the XML agree: net 261.93, GST 13.10, 275.03 CAD due. This is the only file in the set that carries its data twice in one container.
ANSI X12 850 purchase order for Harbour Kitchen Group. Version 004010 transaction set 850 for PO-GRP-1002, control number 850002. 3 PO1 segments carry quantity, X12 unit code, unit price, the supplier item code (VP) and the buyer item code (BP); CTT declares 3 line items and SE declares 14 segments, which is the number actually present between ST and SE inclusive.
ANSI X12 856 despatch advice for Harbour Kitchen Group. Version 004010 transaction set 856 for supplier delivery note DN-GRP-3002 against PO-GRP-1002, control number 856002. The shipment, order and item hierarchy uses HL segments, and the SN1 quantities are the quantities actually delivered, so line 2 reports 22 where the 850 ordered 26.
ANSI X12 810 invoice for Harbour Kitchen Group. Version 004010 transaction set 810 for invoice INV-GRP-5002, control number 810002. 3 IT1 segments, a TXI segment stating GST of 15.49, and a TDS segment of 32541 in implied-decimal cents, which is 325.41 CAD. SE declares 13 segments and 13 are present.
ANSI X12 810 invoice with a wrong SE segment count for Harbour Kitchen Group. Identical to edi-810-invoice.edi except for one element: SE declares 11 segments where 13 are present between ST and SE inclusive. The ISA, GS, GE and IEA control numbers, every data segment and the TDS total of 32541 are unchanged, so a parser that checks only syntax accepts the file and only a parser that recounts segments rejects it.
Printed menu as a Word document for Alder Table Bistro. The same 4 dishes and 3 sections as printed-menu.pdf, laid out as 3 two column Word tables with the price cell right aligned, so the identical layout can be read through a different parser. Core properties are stamped to 2026-09-08 and the package timestamps are fixed, so two runs produce identical bytes.
Printed menu as a Word document for Juniper Corner Cafe. The same 4 dishes and 2 sections as printed-menu.pdf, laid out as 2 two column Word tables with the price cell right aligned, so the identical layout can be read through a different parser. Core properties are stamped to 2026-09-08 and the package timestamps are fixed, so two runs produce identical bytes.
Printed menu as a Word document for Copper Oven Bakery. The same 4 dishes and 2 sections as printed-menu.pdf, laid out as 2 two column Word tables with the price cell right aligned, so the identical layout can be read through a different parser. Core properties are stamped to 2026-09-08 and the package timestamps are fixed, so two runs produce identical bytes.
Printed menu as a Word document for Ember Lane Pizza. The same 4 dishes and 2 sections as printed-menu.pdf, laid out as 2 two column Word tables with the price cell right aligned, so the identical layout can be read through a different parser. Core properties are stamped to 2026-09-08 and the package timestamps are fixed, so two runs produce identical bytes.
Printed menu as a Word document for Cedar Street Tacos. The same 4 dishes and 2 sections as printed-menu.pdf, laid out as 2 two column Word tables with the price cell right aligned, so the identical layout can be read through a different parser. Core properties are stamped to 2026-09-08 and the package timestamps are fixed, so two runs produce identical bytes.
Printed menu as a Word document for Willow Event Kitchen. The same 4 dishes and 2 sections as printed-menu.pdf, laid out as 2 two column Word tables with the price cell right aligned, so the identical layout can be read through a different parser. Core properties are stamped to 2026-09-08 and the package timestamps are fixed, so two runs produce identical bytes.
Printed menu as a Word document for Harbour Kitchen Group. The same 4 dishes and 2 sections as printed-menu.pdf, laid out as 2 two column Word tables with the price cell right aligned, so the identical layout can be read through a different parser. Core properties are stamped to 2026-09-08 and the package timestamps are fixed, so two runs produce identical bytes.
A 500-row dataset of fake but realistic users (name, email, address, date of birth), generated with a fixed seed. Paired with a JSON twin.
The 500-row users dataset as a JSON array: the format twin of the CSV version, for testing import and conversion.
A 1000-row orders dataset whose user_id references the users dataset: a relational fixture for testing joins and import flows. Paired with a JSON twin.
The 1000-row orders dataset as JSON: the format twin of the CSV version, relational to the users dataset.
A small but complete OpenAPI 3.1 description (two paths, three schemas) in JSON, for testing API tooling, mock servers, client codegen, and docs generators.
The same OpenAPI 3.1 description in YAML: the format most API definitions ship in. Paired with the JSON twin for testing YAML↔JSON conversion and spec parsers.
A GraphQL Schema Definition Language (SDL) file with queries, a mutation, object/input types, and an enum, for testing GraphQL schema parsers, linters, and code generators.
A proto3 Protocol Buffers schema with messages, an enum, and a repeated field, for testing protobuf compilers (protoc), codegen, and schema tooling.
Page 1 of a paginated JSON API response (users), with page metadata and a `hasMore` flag. Paired with page 2 for testing pagination and infinite-scroll logic.
Page 2 (the final page) of a paginated JSON API response. Paired with page 1 for testing pagination, `hasMore` handling, and list merging.
A 404 error body in RFC 9457 (problem+json) form, with type, title, status, detail, and instance, for testing structured error handling and problem-detail parsers.
A 422 validation-error response with a machine-readable list of field errors, for testing form-validation surfacing and error mapping.
A sample environment (.env) file with typical configuration keys and placeholder values, for testing dotenv parsers and config loaders. Contains no real secrets.
A sample multi-stage Dockerfile with a build stage and a slim runtime stage, for testing Dockerfile parsers, linters (hadolint), and syntax highlighting. Illustrative only.
A sample docker-compose file defining a web service with Postgres and Redis dependencies, for testing Compose parsers and YAML tooling.
A W3C Web App Manifest (JSON) with name, theme colours, and icon set, for testing PWA install prompts and manifest validators.
A small employee table as Apache Parquet: the columnar format at the heart of modern data lakes and analytics. For testing Parquet readers (pandas, Spark, DuckDB) and conversion.
The same employee table as Apache ORC: the columnar format common in the Hive/Hadoop ecosystem. For testing ORC readers and Parquet↔ORC conversion.
The same table as Feather (Arrow IPC file): the zero-copy on-disk form of an Apache Arrow table. For testing Arrow readers and fast columnar interchange.
The same records as Apache Avro: a compact row-based binary format that embeds its own schema, widely used in Kafka pipelines. For testing Avro decoders and schema evolution.
The records as MessagePack: a compact binary serialization that maps onto the JSON data model, common in caches and RPC. For testing MessagePack codecs and JSON↔MessagePack conversion.
The records as CBOR: the IETF concise binary object representation used in IoT and COSE/WebAuthn. For testing CBOR decoders and JSON↔CBOR conversion.
The records as BSON: the binary-JSON encoding MongoDB stores documents in. For testing BSON decoders and JSON↔BSON conversion.
A small HDF5 file with a compound 'employees' dataset and a numeric 'readings' grid: the hierarchical format used across science and ML. For testing h5py/HDF5 readers and conversion.
The employee table as a dBase (DBF) file: the venerable xBase table format still emitted by GIS tools and legacy databases. For testing DBF readers and DBF→CSV conversion.
A single protobuf User message in binary wire format (varint + length-delimited fields): the serialized counterpart to the user.proto schema. For testing protobuf decoders without the generated code.
A realistic e-commerce product catalogue (200 rows): part of a relational dataset (products, customers, orders) with CSV, JSON, SQL, and Parquet twins for testing joins, imports, and conversion.
The e-commerce products table as a JSON array: the format twin of the CSV, for import and conversion testing.
The e-commerce products table as Apache Parquet: the columnar twin, for testing analytics engines (pandas, DuckDB, Spark).
A realistic e-commerce customer directory (500 rows): part of a relational dataset (products, customers, orders) with CSV, JSON, SQL, and Parquet twins for testing joins, imports, and conversion.
The e-commerce customers table as a JSON array: the format twin of the CSV, for import and conversion testing.
A realistic e-commerce order lines (customer_id → customers, product_id → products) (2000 rows): part of a relational dataset (products, customers, orders) with CSV, JSON, SQL, and Parquet twins for testing joins, imports, and conversion.
The e-commerce orders table as a JSON array: the format twin of the CSV, for import and conversion testing.
The e-commerce orders table as Apache Parquet: the columnar twin, for testing analytics engines (pandas, DuckDB, Spark).
A relational SQL schema (products, customers, orders with primary and foreign keys) plus sample INSERTs: the DDL twin of the e-commerce dataset, for testing schema import and migrations.
A year of daily OHLCV stock candles (open/high/low/close/volume) as a seeded random walk: a realistic finance time-series for testing charting, indicators, and importers. JSON twin included.
A day of IoT sensor readings (temperature, humidity, pressure) at one-minute intervals from three sensors, with a realistic daily cycle plus noise, for testing time-series ingestion and downsampling. JSON twin included.
A sample HL7 FHIR R4 bundle with a Patient plus vital-sign Observations, an Encounter, and a Condition: a realistic healthcare-interoperability fixture for testing FHIR parsers and mappers. Synthetic data, not a real person.
A 50,000-row transactions dataset: an in-repo 'large' fixture for testing streaming CSV parsers, import performance, and pagination. Deterministic (fixed seed).
A valid Jupyter notebook (nbformat 4.5) with markdown cells, code cells, and real outputs (stdout stream and an execute result), for testing notebook parsers, nbconvert, and JSON tooling.
A Mermaid flowchart of an order-fulfilment process as diagrams-as-code, for testing Mermaid rendering, diagram-to-image conversion, and Markdown pipelines that embed Mermaid.
A Graphviz DOT directed graph describing a fulfilment pipeline, for testing DOT parsing, Graphviz rendering, and DOT-to-SVG/PNG conversion.
A PlantUML sequence diagram of an order interaction (customer, store, warehouse) as diagrams-as-code, for testing PlantUML parsing and diagram rendering pipelines.
A draw.io (diagrams.net) diagram in its native mxGraphModel XML (a small flowchart) for testing draw.io import/export and XML parsing of diagram files.
A sample JSON Web Token (JWT) signed with HS256 using a published example secret (verifiable but powerless) for testing JWT decoders and validators. Sample only, never for production. Paired with its decoded claims.
The date dimension of a star schema: one row per day with a YYYYMMDD surrogate key and calendar attributes (year, quarter, month, weekday). Joins to the sales fact table on date_key.
The product dimension of a star schema: surrogate key, SKU, name, category, and unit price. Joins to the sales fact table on product_key.
The customer dimension of a star schema: surrogate key, name, city, country, and segment. Joins to the sales fact table on customer_key. Names are synthetic.
The sales fact table at the centre of a star schema: 300 sale lines with foreign keys to the date, product, and customer dimensions plus quantity and amount measures. A fixture for testing joins, star-schema imports, and BI tools.
A small synthetic social network in GraphML: 12 people in two communities with a few bridging ties, carrying node attributes (name, age, community) and weighted edges. Twinned with a GEXF file for testing graph importers and format converters.
The same 12-person social network in GEXF 1.3 (Gephi's native format): node attributes and weighted edges. The format twin of the GraphML file, for testing Gephi imports and GraphML↔GEXF conversion.
A curated world-cities dataset: 40 major cities with country, latitude, longitude, and population. A realistic geospatial fixture for testing map plots, geocoding, and CSV→GeoJSON conversion. GeoJSON twin included.
The same 40 world cities as a GeoJSON FeatureCollection of Points (longitude, latitude order per RFC 7946), each with name, country, and population properties. The mapping twin of the CSV, for testing GeoJSON parsers and map renderers.
A customer-survey response set: 60 respondents rating five statements on a 1–5 Likert scale plus a 0–10 NPS score and a segment. A fixture for testing survey analysis, aggregation, and NPS/CSAT calculations.
A bank-transaction statement: 60 debits and credits across three accounts (masked numbers) with running balances, categories, and merchants. Synthetic data for testing statement parsers, categorisation, and reconciliation.
The bank transactions as a JSON array: the format twin of the CSV, for import and reconciliation testing.
A sample ISO 20022 customer credit-transfer initiation (pain.001.001.09): a single payment with debtor/creditor parties, IBANs, BICs, amount, and remittance info. IBANs are published documentation examples; a fixture for testing payment-message parsers and bank integrations.
A property-listings dataset: 30 homes with address, type, price, beds/baths, size, year built, coordinates, and status. Synthetic data for testing listing importers, map plots, and price analytics.
The property listings as a JSON array: the format twin of the CSV, for import and mapping tests.
A flight-schedule dataset: 30 flights with airline, origin/destination airports, departure/arrival times, aircraft, gate, and status. Synthetic data for testing travel apps, schedule parsers, and status boards.
The flight schedule as a JSON array: the format twin of the CSV, for import and display tests.
A 30-day daily weather forecast for one city: high/low temperature, condition, precipitation, wind, and humidity. Synthetic (seeded) data for testing weather widgets, chart tools, and time-series import.
The daily forecast as a JSON array: the format twin of the CSV, for import and charting tests.
A football-style league table: position, played, won/drawn/lost, goals for/against, goal difference, and points for ten teams, derived from a full round of synthetic match results. Paired with the results JSON.
The full round of match results behind the league table: home/away teams, scores, and dates as a JSON array. A fixture for testing sports-data importers and standings calculators.
An employee directory: 30 staff with department, title, hire date, salary, and manager reference. Synthetic HR data for testing org-chart builders, directory imports, and payroll pipelines.
The employee directory as a JSON array: the format twin of the CSV, for HR import testing.
A monthly payroll summary derived from the employee directory: headcount, annual and monthly gross totals, and a per-department breakdown. A fixture for testing finance/HR dashboards and JSON aggregation.
Tiny Parquet table with null name/score/note cells. Tests null handling in columnar readers.
Parquet with dictionary-encoded string column. Tests dictionary page decoding.
Parquet with a struct column. Tests nested type round-trips.
Parquet with a list-of-string column. Tests repeated-field decoding.
Empty Parquet file with schema but no rows: edge case for readers.
Single-row Parquet table: minimal columnar fixture.
Parquet with repeated key values. Tests join/aggregation edge cases.
Parquet with bool/int/string/float columns including a null integer.
SAMPLE .env file (development) for dotenv parser and config-loader tests: placeholders only.
SAMPLE .env file (production-template) for dotenv parser and config-loader tests: placeholders only.
SAMPLE .env file (testing) for dotenv parser and config-loader tests: placeholders only.
SAMPLE .env file (comments-edge) for dotenv parser and config-loader tests: placeholders only.
SAMPLE Kubernetes deployment manifest: fictional names, no real cluster secrets.
SAMPLE Kubernetes service manifest: fictional names, no real cluster secrets.
SAMPLE Kubernetes configmap manifest: fictional names, no real cluster secrets.
SAMPLE Kubernetes secret manifest: fictional names, no real cluster secrets.
SAMPLE Kubernetes ingress manifest: fictional names, no real cluster secrets.
Sample docker-compose override file for merge/extends parser tests.
Minimal nginx reverse-proxy config SAMPLE for syntax highlighter and linter tests.
Sample TOML application config for TOML parser tests.
Sample INI config file for legacy config parser tests.
JSON application settings for config-merge and validation tests.
Minimal CI pipeline YAML for GitHub Actions / GitLab CI parser tests.
Tiny Apache rewrite rules SAMPLE for .htaccess parser tests.
Sample terraform.tfvars with fictional region, for HCL/tfvars parser tests.
AWS credentials file shape with obviously fake keys, for credential scanner and parser tests.
Feather/Arrow IPC twin of the null-heavy table, grouped with the Parquet nulls fixture.
Feather file with dictionary-encoded strings: Arrow IPC edge-case fixture.
JSON description of nullable columns in the null-heavy columnar fixtures.
Amounts stored as strings in Parquet: common ingestion edge case for ETL parsers.
A weekly five-occurrence series that provides the recurrence baseline before exclusions or additions are applied.
The same weekly series with its third occurrence excluded, for testing RRULE expansion followed by EXDATE filtering.
A recurrence set with both an exclusion and an explicit addition, useful for catching expansion engines that apply only one modifier.
A TZID-qualified event immediately after Toronto's spring-forward boundary, with an explicit VTIMEZONE definition.
The UTC representation of the Toronto event, providing an exact normalization target for calendar importers.
A floating-time variant with no TZID or Z suffix, for verifying that parsers do not silently reinterpret local wall time as UTC.
The invitation that starts a scheduling lifecycle, using stable UID and organizer/attendee identities.
An attendee acceptance for the same meeting, used to test UID correlation and PARTSTAT state updates.
The terminal cancellation for the scheduling group, checking METHOD, STATUS, UID and sequence precedence together.
A standards-conforming event with a folded content line and UTF-8 text for baseline parser and line-unfolding tests.
A complete iCalendar structure using LF-only line endings, a common recoverable export defect for tolerant parser tests.
An intentionally corrupt iCalendar file whose VEVENT is never closed, for testing fatal component-nesting errors without using a large or hostile payload.
A fictional multilingual contact for checking Unicode decoding and round trips between legacy and current vCard versions. This member uses vCard 2.1 syntax.
A fictional multilingual contact for checking Unicode decoding and round trips between legacy and current vCard versions. This member uses vCard 3.0 syntax.
A fictional multilingual contact for checking Unicode decoding and round trips between legacy and current vCard versions. This member uses vCard 4.0 syntax.
A fictional contact with repeated typed properties for testing importers that otherwise keep only the first value. This member uses vCard 2.1 syntax.
A fictional contact with repeated typed properties for testing importers that otherwise keep only the first value. This member uses vCard 3.0 syntax.
A fictional contact with repeated typed properties for testing importers that otherwise keep only the first value. This member uses vCard 4.0 syntax.
A fictional business contact with structured organization and postal-address fields for CRM migration tests. This member uses vCard 2.1 syntax.
A fictional business contact with structured organization and postal-address fields for CRM migration tests. This member uses vCard 3.0 syntax.
A fictional business contact with structured organization and postal-address fields for CRM migration tests. This member uses vCard 4.0 syntax.
A fictional contact carrying the same tiny portrait in the version-specific photo syntax used by vCard 2.1, 3.0 and 4.0. This member uses vCard 2.1 syntax.
A fictional contact carrying the same tiny portrait in the version-specific photo syntax used by vCard 2.1, 3.0 and 4.0. This member uses vCard 3.0 syntax.
A fictional contact carrying the same tiny portrait in the version-specific photo syntax used by vCard 2.1, 3.0 and 4.0. This member uses vCard 4.0 syntax.
The baseline member of a JSON Schema 2020-12 customer contract. Reference contract: id and name are required strings.
The compatible member of a JSON Schema 2020-12 customer contract. Backward compatible: existing instances remain valid because email is optional.
The breaking member of a JSON Schema 2020-12 customer contract. Breaking relative to baseline: id changes from string to integer and tenantId becomes required.
The baseline member of a complete OpenAPI 3.1 ticket endpoint contract. Reference API: string ticket IDs and required id/summary response properties.
The compatible member of a complete OpenAPI 3.1 ticket endpoint contract. Backward compatible: an optional priority response property is added and existing operations stay unchanged.
The breaking member of a complete OpenAPI 3.1 ticket endpoint contract. Breaking relative to baseline: ticket id becomes integer and status becomes a required response property.
The baseline proto3 Customer message for field-number and wire-compatibility testing. Reference wire contract: field 1 is string id and field 2 is string name.
The compatible proto3 Customer message for field-number and wire-compatibility testing. Backward compatible: existing field numbers/types are retained and optional email uses new field number 3.
The breaking proto3 Customer message for field-number and wire-compatibility testing. Breaking relative to baseline: field number 2 is reused with a different name and wire type.
The baseline Avro record schema for reader/writer compatibility tests. Reference writer schema: id and name are strings.
The compatible Avro record schema for reader/writer compatibility tests. Backward compatible for old records: nullable email is added with a null default.
The breaking Avro record schema for reader/writer compatibility tests. Breaking relative to baseline: id changes to long and tenantId has no default.
A six-stage software pipeline DAG for testing dependency import, cycle checks and reproducible topological sorting. This GraphML member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A six-stage software pipeline DAG for testing dependency import, cycle checks and reproducible topological sorting. This GEXF 1.3 member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A six-stage software pipeline DAG for testing dependency import, cycle checks and reproducible topological sorting. This JSON edge list member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A four-service directed cycle whose only valid topological result is failure, for dependency-analysis regression tests. This GraphML member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A four-service directed cycle whose only valid topological result is failure, for dependency-analysis regression tests. This GEXF 1.3 member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A four-service directed cycle whose only valid topological result is failure, for dependency-analysis regression tests. This JSON edge list member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A directed graph with two linked islands and one isolated node, designed for weak-component and isolated-node tests. This GraphML member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A directed graph with two linked islands and one isolated node, designed for weak-component and isolated-node tests. This GEXF 1.3 member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A directed graph with two linked islands and one isolated node, designed for weak-component and isolated-node tests. This JSON edge list member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A weighted acyclic multigraph with two parallel source-to-router edges, checking multiplicity and floating-point weight preservation. This GraphML member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A weighted acyclic multigraph with two parallel source-to-router edges, checking multiplicity and floating-point weight preservation. This GEXF 1.3 member carries the same node IDs, edge IDs, directions and weights as its two format twins.
A weighted acyclic multigraph with two parallel source-to-router edges, checking multiplicity and floating-point weight preservation. This JSON edge list member carries the same node IDs, edge IDs, directions and weights as its two format twins.
Valid Protobuf wire record with string, uint32, and string fields for schema-guided decoding. Stable P8 artifact p8-convert-protobuf-source.
Proto3 schema companion declaring the three fields used by the binary creator record. Stable P8 artifact p8-convert-protobuf-schema.
Expected JSON semantic result for the schema-guided Protobuf decode. Stable P8 artifact p8-convert-protobuf-expected.
Valid wire bytes intentionally supplied without a matching schema so tools must preserve unknown field 15. Stable P8 artifact p8-convert-protobuf-missing-schema.
Binary orc source for the five-row P8 employee conversion table, preserving ids, names, departments, booleans, and scores. Stable P8 artifact p8-convert-orc-source.
Json semantic reference for the five-row P8 employee conversion table, preserving ids, names, departments, booleans, and scores. Stable P8 artifact p8-convert-orc-json.
Csv semantic reference for the five-row P8 employee conversion table, preserving ids, names, departments, booleans, and scores. Stable P8 artifact p8-convert-orc-csv.
A clean invoice template as a Word document with a line-item table and total. Paired with a PDF twin of the same layout.
The invoice template as a print-ready PDF: the format twin of the DOCX version, for converter testing and direct printing.
A realistic sales quotation with a five-line item table, subtotal, tax, and validity terms, as an editable Word document, twinned with a print-ready PDF.
The sales quotation as a branded, print-ready PDF with a line-item table and totals: the format twin of the DOCX quote, for converter testing and direct sending.
A purchase order with buyer and vendor blocks, a line-item table, totals, and Net-30 terms: an editable Word document paired with a PDF twin.
The purchase order as a branded print-ready PDF with a line-item table and totals: the format twin of the DOCX version for converter and print testing.
A company newsletter as an editable Word document with a masthead and three short articles, twinned with an HTML email version of the same content.
A usable invoice template as OpenDocument Text: header details and an itemised table with subtotal, tax, and total. Open and edit it in any word processor; also a fixture for ODT parsing and conversion.
A budget template as OpenDocument Spreadsheet, budget-versus-actual rows with live SUM formulas for the totals. A usable planning template and a fixture for testing ODS formula parsing and recalculation.
OpenDocument twin of the SAMPLE pitch deck for ODP converters.
Tiny SAMPLE markdown template (agenda-standup) for docs and planning workflows.
Tiny SAMPLE markdown template (agenda-retro) for docs and planning workflows.
Tiny SAMPLE markdown template (status-update) for docs and planning workflows.
Tiny SAMPLE markdown template (release-notes-stub) for docs and planning workflows.
Tiny SAMPLE markdown template (checklist-launch) for docs and planning workflows.
Tiny SAMPLE markdown template (data-subject-request) for docs and planning workflows.
Tiny SAMPLE markdown template (one-pager-outline) for docs and planning workflows.
Tiny SAMPLE markdown template (interview-scorecard) for docs and planning workflows.
A completed discovery questionnaire for a fictional product-launch engagement. This editable Word edition carries the complete shared family model with styled sections and print-safe tables.
A completed discovery questionnaire for a fictional product-launch engagement. This print-ready PDF twin is designed for page-rendering, extraction, and cross-format comparison tests.
A completed discovery questionnaire for a fictional product-launch engagement. This UTF-8 Markdown twin preserves the same headings, lists, checkboxes, and GFM tables in portable plain text.
A blameless operational review with impact, timeline, causal analysis, and owned actions. This editable Word edition carries the complete shared family model with styled sections and print-safe tables.
A blameless operational review with impact, timeline, causal analysis, and owned actions. This print-ready PDF twin is designed for page-rendering, extraction, and cross-format comparison tests.
A blameless operational review with impact, timeline, causal analysis, and owned actions. This UTF-8 Markdown twin preserves the same headings, lists, checkboxes, and GFM tables in portable plain text.
A channel-ready brief connecting one campaign objective to audience insight, messages, assets, and approvals. This editable Word edition carries the complete shared family model with styled sections and print-safe tables.
A channel-ready brief connecting one campaign objective to audience insight, messages, assets, and approvals. This print-ready PDF twin is designed for page-rendering, extraction, and cross-format comparison tests.
A channel-ready brief connecting one campaign objective to audience insight, messages, assets, and approvals. This UTF-8 Markdown twin preserves the same headings, lists, checkboxes, and GFM tables in portable plain text.
A scored delivery-risk register with owners, mitigations, triggers, and review dates. This Excel workbook adds filters, frozen headers, print settings, typed cells, and live formulas where the model defines them.
A scored delivery-risk register with owners, mitigations, triggers, and review dates. This print-ready PDF twin is designed for page-rendering, extraction, and cross-format comparison tests.
A scored delivery-risk register with owners, mitigations, triggers, and review dates. This UTF-8 CSV twin contains the model's single canonical table for parser, import, and round-trip tests.
A minute-by-minute production schedule with cues, ownership, locations, and contingencies. This Excel workbook adds filters, frozen headers, print settings, typed cells, and live formulas where the model defines them.
A minute-by-minute production schedule with cues, ownership, locations, and contingencies. This print-ready PDF twin is designed for page-rendering, extraction, and cross-format comparison tests.
A minute-by-minute production schedule with cues, ownership, locations, and contingencies. This UTF-8 CSV twin contains the model's single canonical table for parser, import, and round-trip tests.
A weighted comparison of fictional vendors with evidence notes, decisions, and review ownership. This Excel workbook adds filters, frozen headers, print settings, typed cells, and live formulas where the model defines them.
A weighted comparison of fictional vendors with evidence notes, decisions, and review ownership. This print-ready PDF twin is designed for page-rendering, extraction, and cross-format comparison tests.
A weighted comparison of fictional vendors with evidence notes, decisions, and review ownership. This UTF-8 CSV twin contains the model's single canonical table for parser, import, and round-trip tests.
A ZIP archive: 3 files at the root, no directories. Deterministic (fixed member timestamps) and safe to extract anywhere.
A ZIP archive: files organised into data/ and docs/ subfolders. Deterministic (fixed member timestamps) and safe to extract anywhere.
A ZIP archive: a file nested six directory levels deep. Deterministic (fixed member timestamps) and safe to extract anywhere.
A ZIP archive, UTF-8 filenames: accents, Japanese, emoji. Deterministic (fixed member timestamps) and safe to extract anywhere.
A ZIP archive: 100 tiny files for throughput testing. Deterministic (fixed member timestamps) and safe to extract anywhere.
A valid ZIP with zero entries: the empty-archive edge case for testing how unarchivers handle a container with nothing inside.
A Java Archive (JAR): a ZIP with a META-INF/MANIFEST.MF and resource files only (no .class bytecode). For testing JAR/ZIP readers and manifest parsing.
A uncompressed USTAR of a small source tree, for testing tar extraction and the TAR container. Member timestamps are fixed for reproducibility.
A gzip-compressed tar of a small source tree, for testing tar extraction and the TGZ container. Member timestamps are fixed for reproducibility.
A bzip2-compressed tar of a small source tree, for testing tar extraction and the TBZ2 container. Member timestamps are fixed for reproducibility.
A xz/LZMA-compressed tar of a small source tree, for testing tar extraction and the TXZ container. Member timestamps are fixed for reproducibility.
A single text file compressed with gzip: the container-free codec on its own, for testing decompression and codec detection.
A single text file compressed with bzip2: the container-free codec on its own, for testing decompression and codec detection.
A single text file compressed with xz/LZMA: the container-free codec on its own, for testing decompression and codec detection.
A 7-Zip archive using LZMA2 compression, containing a small documented file tree. For testing 7z extraction and conversion.
A password-protected 7z archive (AES-256, encrypted header). The password is “novus-example”, printed here on purpose so you can test encrypted-archive extraction. Contains only harmless sample text.
A real ISO 9660 disk image with Joliet and Rock Ridge extensions for long filenames, holding a few documented text files. For testing ISO mounting, extraction, and conversion.
A text file compressed with Zstandard (.zst), the container-free codec on its own, for testing zstd decompression and codec detection.
A text file compressed with the LZ4 frame format (.lz4), the container-free codec on its own, for testing LZ4 decompression and codec detection.
A minimal WARC 1.0 web archive with a warcinfo record and an HTTP response record capturing a small HTML page, for testing WARC parsers and web-archive tooling.
A cpio archive in the newc (SVR4) format with four members: the Unix archive format used by initramfs and RPM. Hand-written to spec and documented down to its member list; for testing cpio extractors and converters.
A Unix ar archive with three members: the simple format that backs static libraries (.a) and Debian packages (.deb). Hand-written to spec; for testing ar extractors and archive tooling.
A realistic static-website project bundled as a ZIP: index.html with linked CSS, JS, and an SVG logo, plus a README. For testing project extraction, unpack-then-serve pipelines, and nested-folder handling.
A dataset bundle ZIP (a CSV with its JSON Schema, a README, and a LICENSE), the way datasets are commonly distributed. For testing unpack-and-validate pipelines and dataset importers.
A small ZIP shaped like a GDPR subject-access export: profile JSON, activity CSV, consents JSON, and a README. All PII is fictional SAMPLE data.
ZIP containing another ZIP plus text, for recursive extractors.
Three-level nested ZIP SAMPLE for deep recursive extraction tests.
Multi-record WARC 1.0 SAMPLE (warcinfo + responses + resource) for web-archive tooling.
Small ZIP SAMPLE (unicode-nested.zip) for extractor and listing tests.
Small ZIP SAMPLE (empty-dirs.zip) for extractor and listing tests.
Small ZIP SAMPLE (mixed-compression.zip) for extractor and listing tests.
Small ZIP SAMPLE (project-slice.zip) for extractor and listing tests.
Small ZIP SAMPLE (docs-bundle.zip) for extractor and listing tests.
Small ZIP SAMPLE (config-bundle.zip) for extractor and listing tests.
Small ZIP SAMPLE (data-bundle.zip) for extractor and listing tests.
Small ZIP SAMPLE (html-site-slice.zip) for extractor and listing tests.
Gzipped tarball SAMPLE companion for nested-archive conversion sets.
Tiny pad ZIP #1 for extractor batch tests.
Tiny pad ZIP #2 for extractor batch tests.
Tiny pad ZIP #3 for extractor batch tests.
Tiny pad ZIP #4 for extractor batch tests.
Tiny pad ZIP #5 for extractor batch tests.
Tiny pad ZIP #6 for extractor batch tests.
Tiny pad ZIP #7 for extractor batch tests.
Tiny pad ZIP #8 for extractor batch tests.
Tiny pad ZIP #9 for extractor batch tests.
Tiny pad ZIP #10 for extractor batch tests.
Tiny pad ZIP #11 for extractor batch tests.
Tiny pad ZIP #12 for extractor batch tests.
SAMPLE subject-access ZIP with JSON profile/preferences only: fictional PII.
SAMPLE nested-folder GDPR export with JSON + JSONL members: fictional PII.
A ZIP whose every member uses compression method 0 (stored). Its twin holds byte-identical content under the other method, so an extractor, a size estimator, or a repacking pipeline can be compared on the same payload with only the storage method changed.
A ZIP whose every member uses compression method 8 (deflate). Its twin holds byte-identical content under the other method, so an extractor, a size estimator, or a repacking pipeline can be compared on the same payload with only the storage method changed.
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.
A ZIP that stores each directory as its own zero-length record with a trailing slash and the MS-DOS directory attribute set. Its group siblings hold the same tree with the directory records implied and with the trailing slash missing, which is the trio an extractor's mkdir logic has to survive.
The same three-directory tree with no directory records at all: the parents exist only as path components inside member names. Extractors that create directories only when they see a directory record fail on this shape, which is what most command-line ZIP writers produce.
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.
Member names stored as UTF-8 with general-purpose bit 11 (the language-encoding flag) set, which is the modern, unambiguous way to carry a non-ASCII filename in a ZIP. Its CP437 twin encodes the same archive the legacy way, so a reader's encoding heuristic can be compared against a case where the answer is declared.
The legacy twin: names encoded in IBM CP437 with the language-encoding flag clear, which is what the ZIP spec says an un-flagged name means. Decoding these bytes as UTF-8 produces mojibake or an outright decode error, which is exactly the bug this file is for.
The third way a ZIP carries a non-ASCII name: an ASCII-safe name in the header plus an Info-ZIP Unicode Path extra field (0x7075) holding the real UTF-8 name and a CRC32 of the header name. A reader must prefer the extra field, but only while that CRC still matches the header name it was computed from.
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.
Two of three members carry a central-directory file comment and the third carries none. Comments exist only in the central directory, so a reader that walks local headers to build its listing loses them entirely; a rewriter that drops them loses them permanently.
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.
The DOS timestamp in a ZIP header has 2-second resolution and no timezone, so Info-ZIP adds a 0x5455 extended timestamp and a 0x7875 uid/gid field. Here the uid/gid field appears in the local header only, matching what Info-ZIP actually writes, so a reader that reads extras from the central directory alone sees the timestamp but loses the ownership.
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.
Unix permissions ride in the top 16 bits of the ZIP external attributes field, and are only meaningful when the version-made-by byte says Unix. This archive carries 0444, 0600, 0664 and a 0750 directory, plus the MS-DOS read-only bit on the 0444 member so the two conventions can be seen disagreeing. Nothing here is marked executable.
share/current.csv is a symbolic link, stored the Info-ZIP way: the external attributes carry S_IFLNK and the member payload is the 16-byte target path rather than file content. The target is relative and resolves inside the archive, so extracting without symlink support produces a harmless text file instead of a dangling or escaping link.
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 deliberately bounded compression-ratio fixture: 4474 bytes on disk expanding to exactly 4 MiB of zeros, roughly 937:1. It is not a decompression bomb - there is no nesting and no recursion, and the expanded size is a fixed 4 MiB - so it exercises a ratio guard or a streaming extractor's memory ceiling without being dangerous to open.
The 1988 POSIX format: 512-byte headers, octal numeric fields, names split across a 155-byte prefix and a 100-byte name, and no mechanism at all for anything that does not fit - including the access and change times its siblings carry. All three archives in this group hold byte-identical members with identical ownership and modification times, so any other difference a reader reports between them comes from the header encoding alone.
GNU tar's extension of the same header, identified by its own magic: long names get their own 'L' record, oversized numeric fields switch to base-256, and sparse files get an in-header map. All three archives in this group hold byte-identical members with identical ownership and modification times, so any other difference a reader reports between them comes from the header encoding alone.
The 2001 POSIX format: anything the classic header cannot express moves into an 'x' extended header of UTF-8 key=value records placed immediately before the member it describes. Here each member carries atime and ctime records, which is why this archive is structurally different from its USTAR twin rather than byte-identical to it. All three archives in this group hold byte-identical members with identical ownership and modification times, so any other difference a reader reports between them comes from the header encoding alone.
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.
PAX is the only tar variant that says what encoding its names are in: extended-header records are UTF-8 by definition. These three members carry accented Spanish and Japanese path components, so a reader that applies a locale-dependent guess instead of trusting the format produces mojibake on exactly this file.
A PAX 'g' global extended header leads the stream, carrying archive-wide key=value records including a vendor-prefixed pair. Readers must apply it to every following member and must not list it as a file - a mistake that shows up as a phantom entry named 'pax_global_header'.
share/current.csv is a symbolic link: typeflag '2', size 0, and the target carried in the header's 100-byte linkname field rather than in any data blocks. The target is relative and stays inside the archive, so extraction is safe with or without symlink support.
share/backup/records.csv is a hard link to a member that appears earlier in the stream, so its content is stored exactly once. Order matters: a reader that extracts members out of sequence, or that copies content instead of linking, changes both the on-disk byte count and the inode relationship the archive is describing.
Three directory records with distinct modes, one of which - tree/empty/ - has no members underneath it and therefore exists only because the record does. A reader that synthesises directories from member paths alone silently loses it, and loses the 0750 and 0700 modes on the other two.
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 uname and gname fields in a tar header are 32 bytes. This archive's second member is owned by a 44-character service-account name, which only fits because PAX moves it into an extended header. A USTAR writer would have truncated it to 31 characters and lost the distinction between two similarly-named accounts.
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 1 MiB file with a 1047552-byte hole in the middle, stored the old GNU way: typeflag 'S' and a four-slot sparse map written into the header block itself. Only 1024 bytes are actually in the stream, so a reader that ignores the map reconstructs a 1024-byte file instead of a 1 MiB one.
The same 1 MiB sparse file in the modern encoding: an 'x' extended header declares GNU.sparse 1.0 and the real name and size, and the segment map is decimal text at the beginning of the member's own data rather than in the header. A reader that honours the records must also strip the GNUSparseFile.0/ prefix from the name it reports.
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.
The same three members followed by the end-of-archive blocks and then zero padding out to a whole 10240-byte record - tar's historical blocking factor of 20, still the default. The archive is 10240 bytes for 616 bytes of content, which is what makes tiny tarballs look so wasteful before compression.
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.
One ZIP holding the same two-member tar in four containers - plain, gzip, xz and bzip2 - so a recursive lister can be checked on four codecs in one pass. The already-compressed members are stored rather than deflated, which is what a competent writer does and what a naive one does not.
A tar carrying three ZIPs: two byte-identical and a third holding the same content stored rather than deflated. A deduplicating packer should notice the first two are the same object; a content-addressed one should notice all three extract to the same files.
A gzipped tar whose second member is another gzipped tar. Tools that apply decompression greedily - gunzip until the bytes stop being gzip - skip straight past the outer tar and report the inner archive's two members as if they were the whole thing.
The nested-JAR layout an executable fat jar uses: a manifest with a Class-Path entry and a second JAR stored uncompressed under BOOT-INF/lib so it can be read in place without being extracted first. It contains resources only - properties, JSON and text, no compiled bytecode - and the manifest uses the CRLF line endings the JAR specification requires.
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.
Valid Zstandard-compressed TAR source 01 with 2 safe members for compound-suffix detection and extraction Stable P8 artifact p8-convert-tar-zst-01.
Valid Zstandard-compressed TAR source 02 with 2 safe members for compound-suffix detection and extraction Stable P8 artifact p8-convert-tar-zst-02.
Valid Zstandard-compressed TAR source 03 with 2 safe members for compound-suffix detection and extraction Stable P8 artifact p8-convert-tar-zst-03.
Tiny intentionally corrupt TAR.ZST with preserved Zstandard magic and a deliberately damaged frame-header byte so strict decompressors reject it before extraction Stable P8 artifact p8-convert-tar-zst-intentionally-corrupt.
Canonical compound-suffix source for the same deterministic bzip2-compressed TAR member set Stable P8 artifact p8-convert-tar-bz2.
Alias-suffix twin for the same deterministic bzip2-compressed TAR member set Stable P8 artifact p8-convert-tbz2-alias.
Canonical compound-suffix source for the same deterministic XZ-compressed TAR member set Stable P8 artifact p8-convert-tar-xz.
Alias-suffix twin for the same deterministic XZ-compressed TAR member set Stable P8 artifact p8-convert-txz-alias.
JSON ground-truth manifest for the canonical compressed-TAR twins, publishing each safe path, byte count, and full SHA-256 digest. Stable P8 artifact p8-convert-archive-member-manifest.
GNU-style SHA-256 list for the two canonical TAR members, preserving relative paths and full lowercase digests. Stable P8 artifact p8-convert-archive-sha256.
Existing-format TGZ control carrying the same two canonical members used by the new compound archive formats Stable P8 artifact p8-convert-tgz-alias.
Existing-format ZIP extraction control for comparing member-path and hash behavior with the compressed-TAR cohort Stable P8 artifact p8-convert-zip-extraction-control.
Valid single-file Microsoft Cabinet using uncompressed CFDATA for bounded legacy extraction tests Stable P8 artifact p8-convert-legacy-cab.
Valid RAR4 archive with two stored members and fixed metadata for legacy extraction tests Stable P8 artifact p8-convert-legacy-rar.
Existing-format ZIP/TXT media control combining a plain README and a WebVTT sidecar for nested media extraction checks Stable P8 artifact p8-convert-legacy-archive-media-control.
A valid EPUB 3 e-book with a cover image, an EPUB navigation document, styled chapters, and a correctly stored OCF mimetype. Original content, for testing EPUB readers and EPUB→other conversion.
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.
A FictionBook (FB2) e-book: a single self-contained XML file with full title and document metadata and three chapters. Popular in e-reader ecosystems; for testing FB2 parsers and FB2→EPUB conversion.
A CBZ comic archive: a ZIP of sequentially named JPEG pages, the standard container for digital comics. Built from generated pages; for testing comic readers and CBZ→PDF conversion.
The valid EPUB converted to MOBI (Mobipocket) with Calibre: the classic Kindle format. For testing MOBI readers and EPUB→MOBI conversion.
The valid EPUB converted to AZW3 (Kindle KF8) with Calibre: the modern Kindle format. For testing AZW3 readers and EPUB→AZW3 conversion.
A valid EPUB 2.0.1 e-book navigated by an NCX table of contents and an OPF <guide>, with a cover: the older EPUB edition. Paired with an identical EPUB 3 twin for testing EPUB2↔EPUB3 conversion.
The same book as EPUB 3, navigated by an XHTML navigation document (with an NCX fallback for older readers). The modern twin in an EPUB2↔EPUB3 conversion set.
A six-chapter original short novel as EPUB 3, with a cover and navigation: longer, real narrative prose for testing paginators, readers, reflow, and EPUB conversion at a realistic length. Original content, free to use.
An EPUB 3 sample styled with a serif stylesheet. Pair with the sans CSS twin for reader CSS tests.
The same SAMPLE book content with a sans-serif stylesheet: CSS twin of the serif EPUB.
A minimal FictionBook (.fb2) SAMPLE with one section, for FB2/XML ebook importers.
EPUB 3 SAMPLE with landmarks nav for reader TOC/landmark tests.
EPUB 3 SAMPLE with landmarks nav for reader TOC/landmark tests.
EPUB 3 SAMPLE without landmarks nav for reader TOC/landmark tests.
EPUB 3 SAMPLE with landmarks nav for reader TOC/landmark tests.
Additional EPUB 3 SAMPLE volume 5 with landmarks for batch reader tests.
Additional EPUB 3 SAMPLE volume 6 with landmarks for batch reader tests.
Additional EPUB 3 SAMPLE volume 7 with landmarks for batch reader tests.
Additional EPUB 3 SAMPLE volume 8 with landmarks for batch reader tests.
Additional EPUB 3 SAMPLE volume 9 with landmarks for batch reader tests.
Additional EPUB 3 SAMPLE volume 10 with landmarks for batch reader tests.
Plain-text landmark note SAMPLE #1 companion for EPUB nav tests.
Plain-text landmark note SAMPLE #2 companion for EPUB nav tests.
Plain-text landmark note SAMPLE #3 companion for EPUB nav tests.
Plain-text landmark note SAMPLE #4 companion for EPUB nav tests.
Plain-text landmark note SAMPLE #5 companion for EPUB nav tests.
Plain-text landmark note SAMPLE #6 companion for EPUB nav tests.
Plain-text landmark note SAMPLE #7 companion for EPUB nav tests.
Plain-text landmark note SAMPLE #8 companion for EPUB nav tests.
A fixed-layout EPUB 3: rendition:layout is pre-paginated, every page declares a 600x800 viewport, and all content is absolutely positioned. Paired with a reflowable twin carrying the same words, so you can see which of the two a reader is actually honouring.
The reflowable twin of the fixed-layout plate book: rendition:layout is reflowable, nothing is absolutely positioned, and the text is free to rewrap. Use it as the control when checking whether a reader honours the pre-paginated flag or silently reflows everything.
A fixed-layout EPUB 3 that asks for synthetic spreads in landscape and pins each page to a side with rendition:page-spread-left and rendition:page-spread-right. For testing two-up spread rendering and the side assignment readers get wrong first.
A fixed-layout EPUB 3 that requests a portrait orientation lock and suppresses spreads entirely. For testing whether a reader applies rendition:orientation, ignores it, or rotates the content anyway on a landscape device.
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.
An EPUB 3 with a real media overlay: a SMIL document ties three paragraph ids to clip ranges in an embedded MP3, and the package declares media:duration and media:active-class. The narration track is deliberately silent audio, so the fixture stays small and byte-identical on every run.
Three chapters, three SMIL overlays and three MP3 tracks, with a media:duration refines entry per overlay plus the package total. For testing whether a reader plays continuously across document boundaries and whether it sums the per-document durations correctly.
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 EPUB 3 that embeds a TrueType face through @font-face with no obfuscation and no META-INF/encryption.xml. The control member of the obfuscation set: extract the font and it is a working TTF.
The same book with its embedded font obfuscated by the IDPF algorithm: the first 1040 bytes are XORed with the SHA-1 of the whitespace-stripped unique identifier, and META-INF/encryption.xml declares it. Paired with the plain-embedding twin so a de-obfuscator can be checked byte for byte.
The same book obfuscated the other way: Adobe's scheme XORs the first 1024 bytes with the sixteen raw bytes of the identifier UUID. Two schemes, two byte counts, two algorithm URIs - the pair that catches a reader which implements only one and assumes the other.
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.
A conforming EPUB 3 navigated solely by an XHTML navigation document, with no NCX fallback at all. The modern baseline, and the twin of the NCX-only book that inverts it.
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.
The dual-navigation build every commercial EPUB 3 ships: an XHTML navigation document for EPUB 3 readers and a matching NCX for EPUB 2 ones, listing the same three chapters in the same order.
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 EPUB 3 carrying print-page navigation: a hidden page-list nav, matching pagebreak markers in the content with doc-pagebreak roles, and an equivalent NCX pageList. For testing go-to-page features and the page-number reporting that accessibility conformance asks for.
An EPUB 3 in Arabic that declares page-progression-direction="rtl" in the spine, dir="rtl" on the body, and a right-aligned stylesheet. Paired with a left-to-right control carrying the same structure, so a reader's page-turn direction can be checked rather than assumed.
The right-to-left case again in an unconnected script: Hebrew, with the same rtl spine direction and body dir. Arabic shaping and Hebrew ordering fail independently, so a reader that handles one is not proven to handle the other.
A Japanese EPUB 3 set in vertical-rl, declaring writing-mode with the standard property plus the -epub- and -webkit- prefixes readers actually implement, and an rtl spine so pages turn the way a tategaki book does.
Left-to-right prose with an Arabic run isolated by dir="rtl" and a Latin identifier isolated by dir="ltr" inside an Arabic phrase. The everyday bidi case that breaks when a renderer applies paragraph direction to every character in the paragraph.
The left-to-right control for the direction set: identical package structure to the Arabic fixture, differing only in the language tag and the spine direction. A reference point, not a test case on its own.
An EPUB 3 with a block MathML equation and the required properties="mathml" on its content document. The baseline for MathML support, paired with a twin that omits the declaration.
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 same equation carrying the fallbacks a reader without a MathML engine needs: an altimg raster, its declared dimensions and baseline offset, and an alttext reading of the formula for speech. For testing fallback selection and what a screen reader announces.
An EPUB 3 whose first spine item is an SVG content document rather than XHTML, followed by a chapter that explains what should have appeared. For testing readers that assume every reading-order document is XHTML.
SVG written straight into an XHTML content document, with properties="svg" declared on the manifest item as EPUB 3 requires. The other half of the SVG question: inline vector markup rather than a standalone content document.
A fixed-layout cover built as an SVG content document that pulls in a PNG through xlink:href and centres it as a single-page spread. For testing cover extraction, which usually looks for a raster and finds vector markup instead.
A navigation document nested four levels deep with ordered lists inside list items, targeting heading anchors inside two part documents. Paired with a flattened twin so a reader that silently collapses hierarchy is easy to spot.
The same four-level hierarchy expressed as nested NCX navPoints with a depth-first playOrder and a matching dtb:depth, alongside the equivalent nav document. For testing the older navigation path, which nests through element containment rather than through lists.
Exactly the same content and the same set of targets, listed as one flat level. The reference twin for the nested navigation fixture: if a reader renders both identically, it is discarding hierarchy.
Three linear chapters followed by endnotes and a colophon marked linear="no": present in the package and linked from the text, but outside the page-through sequence. The single most misread spine attribute in EPUB.
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.
Two dc:title elements distinguished only by refines chains into title-type and display-seq, a creator with file-as and a MARC relator role, and a series declared with belongs-to-collection. The structure a catalogue actually needs, and the one flat metadata readers collapse into a single confused string.
A plain EPUB 2.0.1 build of a two-chapter book: NCX navigation, an OPF guide with cover and text references, and the meta name="cover" convention. One third of a conversion set that also ships as EPUB 3 and FB2.
The EPUB 3 build of the same two chapters: an XHTML navigation document with an NCX kept for older readers, and the cover declared as a manifest property. The middle member of the EPUB2 / EPUB3 / FB2 conversion set.
The FictionBook build of the same two chapters: one self-contained XML file with a description block, no container and no manifest. The third member of the conversion set, and the one that has to invent an equivalent for everything the EPUB package documents declare.
An EPUB 2.0.1 that records print pagination the older way: an NCX pageList of pageTarget elements pointing at anchors in the text. The EPUB 2 counterpart of the EPUB 3 page-list nav, and what a converter has to translate between.
The cover convention that predates every standard way of doing it: a bare meta name="cover" pointing at a manifest id, with no guide reference, no cover XHTML page and nothing in the spine. For testing cover extraction against the messiest of the three EPUB 2 conventions.
A FictionBook whose cover is a base64-encoded PNG in a binary element at the foot of the file, wired to a coverpage in the description by xlink id. For testing FB2 image extraction and the converters that have to turn that blob back into a real file.
A FictionBook nested three sections deep, with prose directly inside an outer section, an epigraph, a cite block, and a footnote linking into a second body named notes. The FB2 equivalents of a multi-level table of contents and non-linear back matter, in one file.
A Cyrillic FictionBook stored in windows-1251 and declaring that encoding in its XML declaration - the single-byte legacy encoding a large share of real FB2 files still use. For testing importers that assume every XML file is UTF-8 and produce mojibake instead of an error.
An EPUB 3 whose one content document declares properties="scripted" and contains a single inline script that rewrites one paragraph. It makes no network request and reads correctly with scripting switched off, so it tests the property and the fallback rather than the script.
A plain-text index of every EPUB and FB2 fixture in this wave: its validity class, its subcategory, and the scenario and expected result published for it. Generated from the same entry list that builds the catalogue, so it cannot describe a file that is not there.
DRM-free AZW/MOBI7 e-book source copied byte-for-byte from the catalog's valid reader fixture for legacy import testing. Stable P8 artifact p8-convert-legacy-azw.
Valid CBR comic container with two deterministic PNG pages in lexical reading order for legacy comic conversion. Stable P8 artifact p8-convert-legacy-cbr.
A 10 mm cube as ASCII STL, human-readable facet/normal/vertex records. The most portable 3D-print mesh format; for testing STL parsers and slicers.
The same 10 mm cube as binary STL: an 80-byte header, a triangle count, and packed little-endian floats. Compact; for testing binary-STL readers.
A 10 mm cube as a Wavefront OBJ, plain-text vertices and triangular faces, the lingua franca of 3D asset exchange. For testing OBJ importers and conversion.
A 10 mm cube as 3MF: the modern OPC-packaged manufacturing format (a ZIP of model XML plus relationships). For testing 3MF readers and slicers.
A 10 mm cube as binary glTF (GLB): the dominant modern format for 3D on the web and in AR, with per-face normals packed into one self-contained file. Powers the interactive 3D preview on this site; for testing glTF loaders and conversion.
A 10 mm cube drawn as 12 DXF LINE entities: the AutoCAD interchange format, written with ezdxf. For testing DXF parsers and CAD conversion.
An isometric cube as Encapsulated PostScript: a 2D vector illustration with three shaded faces. For testing EPS/PostScript rendering and vector conversion.
A minimal, well-formed STEP AP214 file holding the eight corner points of a 10 mm cube. For testing STEP header and entity parsing and CAD-exchange tooling.
A minimal, well-formed IGES 5.3 file with a single LINE entity and correct Start/Global/Directory/Parameter/Terminate sections. For testing IGES parsers and CAD conversion.
A 10 mm cube as text glTF 2.0: the JSON scene with its binary buffer embedded as a data URI, the human-readable sibling of the GLB. For testing glTF parsers and GLB↔glTF conversion.
A 10 mm cube as ASCII PLY (Stanford polygon format), plain-text vertex and face lists common in 3D scanning and research. For testing PLY parsers and conversion.
The same cube as binary little-endian PLY: the compact form of the Stanford polygon format. For testing binary-PLY readers.
A 10 mm cube as OFF (Object File Format): the minimal vertex/face text format from Geomview, common in computational geometry. For testing OFF parsers and conversion.
A 10 mm cube as COLLADA (.dae): the XML digital-asset-exchange format used across 3D tools and game engines. For testing COLLADA parsers and conversion.
A 10 mm cube as VRML97 (.wrl): the classic Virtual Reality Modeling Language scene format, ancestor of X3D. For testing VRML parsers and conversion.
A 10 mm cube as X3D: the XML successor to VRML for web and interchange 3D. For testing X3D parsers and VRML↔X3D conversion.
A 10 mm cube as USDZ: Pixar's Universal Scene Description packaged as a stored zip, the format Apple uses for AR Quick Look. For testing USD/USDZ readers and conversion.
A low-poly coffee mug (a cylindrical body with a looped handle) as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
A low-poly house (walls, a door, and a pitched roof) as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
A low-poly tree (a trunk with three stacked conical layers) as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
A low-poly chair (a seat, four legs, and a backrest) as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
A low-poly robot (a stacked-box character with a head, arms, legs, and antenna) as a self-contained vertex-coloured GLB. Real, recognisable geometry (not a primitive) for testing glTF loaders, the 3D viewer, and thumbnailers.
A procedurally-built teapot (a surface-of-revolution body and lid with a stepped spout, a torus handle, and a knob) as a self-contained GLB. The classic teapot shape, for testing 3D loaders and the model viewer.
A UV-mapped cube with an embedded 128×128 checkerboard PNG texture and a PBR material, all packed into one self-contained GLB. A fixture for testing texture and UV handling, embedded-image extraction, and PBR material loading.
A cube with a different colour at each of its eight vertices, interpolated across the faces (COLOR_0 attribute), as a GLB. Paired with a PLY twin, for testing per-vertex colour handling.
The same per-vertex-coloured cube as ASCII PLY with red/green/blue vertex properties: the Stanford-format twin of the GLB, for testing PLY colour parsing.
A 1,200-point coloured point cloud arranged on a sphere via a Fibonacci lattice: a vertex-only PLY (no faces), the format scanners and LiDAR tools produce. Paired with a GLB (POINTS) twin, for testing point-cloud loaders.
The same 1,200-point coloured sphere as a GLB using the POINTS primitive mode, for testing point-cloud rendering in glTF viewers.
A 16-tooth spur-gear profile as a closed DXF polyline with a central hub bore: real parametric CAD geometry (not a primitive). For testing DXF parsers, CAM tools, and CAD conversion.
The same 16-tooth spur-gear profile as STEP AP214 CARTESIAN_POINT entities: the CAD-exchange twin of the DXF, for testing STEP parsing.
Minimal textured glTF SAMPLE (external PNG + BIN) for glTF loaders and material tests.
64×64 albedo PNG companion for the textured mini glTF.
Wavefront OBJ textured quad SAMPLE with MTL reference.
MTL material SAMPLE pairing with the textured OBJ.
Tiny ASCII STL SAMPLE (tetra) for mesh importer smoke tests.
Tiny ASCII STL SAMPLE (pyramid) for mesh importer smoke tests.
Tiny ASCII STL SAMPLE (wedge) for mesh importer smoke tests.
Tiny ASCII STL SAMPLE (slab) for mesh importer smoke tests.
Tiny ASCII STL SAMPLE (corner) for mesh importer smoke tests.
Mesh metadata note SAMPLE #1 for 3D asset pipelines.
Mesh metadata note SAMPLE #2 for 3D asset pipelines.
Mesh metadata note SAMPLE #3 for 3D asset pipelines.
Mesh metadata note SAMPLE #4 for 3D asset pipelines.
Mesh metadata note SAMPLE #5 for 3D asset pipelines.
Mesh metadata note SAMPLE #6 for 3D asset pipelines.
Binary buffer companion for the textured mini glTF (positions, UVs, indices).
A tube skinned to a two-joint chain with inverse bind matrices, unsigned-byte JOINTS_0 and float WEIGHTS_0, plus a three-second rotation animation on the elbow. The shipped models category had no skinned mesh at all; this is the smallest complete one: rig, bind pose, weights and clip in a single self-contained GLB.
The same two-joint skinned bend as readable glTF JSON with its buffer embedded as a base64 data URI: the file to open in a text editor when a GLB's skin, sampler or inverse bind matrices are not doing what you expect.
A longer tube skinned to a four-joint chain, every joint but the root animated, so the whole limb curls rather than hinging once. Exercises joint-matrix accumulation down a hierarchy: the step that a two-bone rig cannot catch.
One cube on one node, with translation, rotation and scale each driven by a five-key sampler that is linearly interpolated. Three files differing only in `interpolation`: the cleanest way to prove an animation player implements all three modes rather than treating everything as linear.
One cube on one node, with translation, rotation and scale each driven by a five-key sampler that is held (STEP): the value jumps at each key. Three files differing only in `interpolation`: the cleanest way to prove an animation player implements all three modes rather than treating everything as linear.
One cube on one node, with translation, rotation and scale each driven by a five-key sampler that is cubic-spline, with in/out tangents stored around each value. Three files differing only in `interpolation`: the cleanest way to prove an animation player implements all three modes rather than treating everything as linear.
A single animation whose four channels drive two nodes at once: the parent's translation, rotation and scale, and a spinning child that inherits all of it. The fixture for checking that channels are applied per node and per path rather than collapsed into one track.
A 16x16 plane with two POSITION morph targets (a sine ripple and a centre bulge), both at weight 0 in the bind pose. Drive the weights yourself to check that a loader adds the deltas to the base positions instead of replacing them.
The same two-target morph plane as readable glTF JSON, so the `targets` array, the mesh-level `weights` and the target accessors can be inspected without a hex editor.
The two-target plane with an animation channel whose target path is `weights`: five keyframes, ten scalars, because a weights sampler stores one value per target per key. The case that breaks players which assume every channel output is a vec3 or a quaternion.
Morph targets that displace both positions and normals, with the first target already at weight 0.3 in the bind pose. Shading that stays flat while the surface ripples is the symptom of a loader that morphs positions and forgets the normal deltas.
Eight POSITION morph targets on one primitive: bumps arranged around a circle, so every active weight is visible independently. Eight is where many real-time renderers stop supporting extra targets; this is the fixture that says whether yours does.
A morph target stored as a sparse accessor: only 25 of 289 vertices carry a delta, and the accessor has no bufferView at all, so every other vertex reads as zero. Sparse accessors are the least-implemented corner of the glTF spec and the usual cause of a target that appears to do nothing.
A sphere with the glTF core metallic-roughness material: full metal, low roughness, no textures, so the numbers in the JSON are the whole material. The baseline half of the metallic-roughness vs specular-glossiness twin.
The same metal expressed in the archived specular-glossiness model, carried in `extensions` with an equivalent metallic-roughness fallback and NOT listed in extensionsRequired. The correct shape for an asset that must keep loading in viewers which dropped specular-glossiness support.
A sphere whose material opts out of lighting entirely via KHR_materials_unlit: the shading path used for baked scenes, maps and stylised art. Renders as a flat silhouette in a conformant viewer and as a lit ball in one that ignores the extension, which makes the difference obvious.
Emission pushed past the core spec's 0-1 emissiveFactor clamp by a 6x strength multiplier: the extension that exists because HDR bloom needs values core glTF cannot express. A tone-mapping and bloom-threshold fixture.
A rough red base under a full-strength, near-mirror clearcoat lobe: the two-layer material that car paint, lacquered wood and phone cases all need. The base and coat roughness differ by an order of magnitude, so a renderer that collapses the layers is obvious.
One mesh, two named material variants (Copper and Cobalt) selectable at runtime: the extension behind every product configurator that swaps a finish without reloading geometry. The primitive also carries a plain `material`, so viewers with no variant support still render something.
Three identical spheres differing only in alphaMode, arranged left to right. The MASK sphere's base alpha (0.45) sits deliberately just under its 0.5 cutoff, so a correct renderer discards it entirely while a renderer that treats MASK as BLEND draws it semi-transparent.
Two open half-shells with identical geometry and opposite `doubleSided` flags. Because the shells are open you can see straight into them, which is the only way to tell backface culling from a lighting difference.
A smooth-shaded sphere as Wavefront OBJ with `mtllib`/`usemtl` pointing at a sibling MTL. Downloading the OBJ alone gives you the classic missing-material case; downloading both reproduces the glTF metallic-roughness twin in this group.
The material library for the OBJ in this group, carrying both the original Phong fields and the de-facto PBR extensions (Pr roughness, Pm metallic, Ke emissive). The file that tells you whether an importer reads MTL's PBR additions or only its 1995 subset.
The same sphere and the same brushed-metal material as the OBJ+MTL pair in this group, but as a single self-contained GLB. Convert the OBJ+MTL and diff against this to score an OBJ-to-glTF material converter.
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.
The same sphere with its buffer inlined as a base64 data URI: one self-contained text file, at roughly a third more bytes than the binary it encodes. The middle point of the three storage strategies in this group.
The third storage strategy for the identical sphere: a GLB whose buffer is the BIN chunk, with no URI at all. Compare the three file sizes in this group to see exactly what base64 and JSON whitespace cost.
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.
The 64x64 two-colour checker referenced by the external-texture glTF in this group. Small, hard-edged and axis-aligned on purpose: UV seams, wrap mode and filter choices are all visible at a glance.
The same textured sphere with the PNG inlined as a base64 data URI in `images[0].uri`: a single portable text file. The variant that makes a glTF e-mailable and that some loaders quietly refuse.
The third texture-storage strategy: the PNG lives inside the GLB's BIN chunk as a bufferView, addressed by `mimeType` rather than a URI. This is what a GLB packer must produce, and extracting the image again is the round-trip test.
Position, normal and UV packed into ONE bufferView with byteStride 32 and three accessors at offsets 0, 12 and 24: the GPU-friendly layout, and the one a naive parser mis-reads because it assumes each accessor owns its view. Twinned here with a tightly-packed version of the same sphere.
The same sphere with every attribute in its own bufferView and no byteStride: the layout most exporters emit and most parsers assume. The control against which the interleaved twin in this group is diffed.
An unquantised sphere: 32-bit floats for both positions and normals, 24 bytes of attribute data per vertex. The uncompressed reference for the quantized and gzip twins in this group.
The same sphere with positions as normalised 16-bit and normals as normalised 8-bit integers under KHR_mesh_quantization: 66.6% of the float32 twin's bytes. The extension is in extensionsRequired, so a loader without support must refuse the file rather than render garbage.
The float32 GLB from this group as a deterministic gzip stream (no embedded filename, mtime 0), what a CDN actually sends when a viewer advertises `Accept-Encoding: gzip`. It compresses to 29.2% of its source against 55.6% for the quantized twin, which is the point of shipping both: quantisation halves the file on disk and then gives most of that back over the wire.
The quantized GLB from this group as a deterministic gzip stream (no embedded filename, mtime 0), what a CDN actually sends when a viewer advertises `Accept-Encoding: gzip`. It compresses to 55.6% of its source against 29.2% for the float32 twin, which is the point of shipping both: quantisation halves the file on disk and then gives most of that back over the wire.
One box mesh referenced by a 24-deep chain of nodes, each adding a translation, an 11-degree rotation and a 0.94 scale, so the result spirals. Any error in matrix accumulation compounds visibly by the tip instead of hiding in rounding.
The 24-level spiral as readable JSON, so the `children` arrays and per-level TRS can be traced by eye. Useful when a converter flattens or re-parents a hierarchy and you need to see exactly where.
Six cubes in a ring whose nodes carry a column-major 4x4 `matrix` and no translation/rotation/scale keys: the encoding a DCC exporter uses when a transform cannot be decomposed. Paired with a TRS twin of the identical ring.
The same six-cube ring with translation, quaternion rotation and scale spelled out per node. Read it next to the matrix twin to check a decomposition routine, or to confirm that your quaternion component order really is xyzw.
An 8x8 field of columns built from a single 12-triangle mesh referenced by 64 nodes with seeded random heights. Core-glTF instancing needs no extension: the file is tiny, and the interesting question is whether your renderer batches the 64 draws or issues them one by one.
Twelve nodes reference one sphere mesh, in three groups whose parents each apply a different rotation and scale. The fixture for importers that copy geometry per node: a correct import keeps one mesh resource with twelve transforms, a naive one produces twelve meshes.
Thirty-two copies of one cube expressed as instance attribute accessors on a single node under EXT_mesh_gpu_instancing: the extension that moves instancing off the scene graph and onto the GPU. A viewer without support shows exactly one cube at the origin, which is the tell.
Three named scenes over three meshes, with the asset's `scene` property pointing at index 1 rather than 0. Loaders that hardcode scene 0 show the wrong content and never report an error: this is the file that catches them.
The three-scene asset as readable JSON, where the top-level `"scene": 1` is one line you can point at in a bug report. Also the fixture for round-tripping multi-scene assets through tools that keep only one scene.
A 1.12 m signpost with its coordinates written in metres, so this file's numbers read up to 1.12. glTF has no unit field: the spec simply says metres, which means a wrongly-scaled export is indistinguishable from a genuinely enormous model until something is measured.
A 1.12 m signpost with its coordinates written in centimetres, so this file's numbers read up to 112. glTF has no unit field: the spec simply says metres, which means a wrongly-scaled export is indistinguishable from a genuinely enormous model until something is measured.
A 1.12 m signpost with its coordinates written in millimetres, so this file's numbers read up to 1120. glTF has no unit field: the spec simply says metres, which means a wrongly-scaled export is indistinguishable from a genuinely enormous model until something is measured.
The same signpost as OBJ with coordinates in metres. OBJ has no unit record of any kind, so the two OBJ files in this group are byte-different and semantically identical: the ambiguity that every OBJ import dialog's scale box exists to resolve.
The same signpost as OBJ with coordinates in millimetres. OBJ has no unit record of any kind, so the two OBJ files in this group are byte-different and semantically identical: the ambiguity that every OBJ import dialog's scale box exists to resolve.
The signpost in millimetres as ASCII STL. STL has no unit field either, but every slicer assumes millimetres, which is why an STL exported in metres arrives as a 1 mm speck and one exported in inches arrives 25.4x too big.
The signpost authored +Y up, which is what the glTF specification mandates and what every conformant viewer assumes. The conformant half of the axis pair: load it, confirm the post stands, and you have calibrated your viewer before testing the Z-up twin.
The same signpost as COLLADA with `<up_axis>Y_UP</up_axis>` and `<unit meter="1" name="metre"/>` in its asset block. Unlike glTF, OBJ and STL, COLLADA states its convention, so an importer that still gets the orientation wrong has no excuse.
The signpost as ASCII PLY with +Y up. PLY has no axis or unit element, so the convention survives only as a header comment that no parser reads: the reason scan data so often arrives rotated.
The signpost as USDZ with `upAxis = "Y"` and `metersPerUnit = 1` in the stage metadata. USD is the only format in this group that declares BOTH the axis and the scale, which is exactly why it is the one AR pipelines standardised on.
The same signpost authored +Z up: what a Blender or 3ds Max glTF export produces when the axis conversion is skipped. glTF has no field in which to declare this, so the file is indistinguishable from a model that genuinely lies on its back, and every conformant viewer will show it that way.
The same signpost as COLLADA with `<up_axis>Z_UP</up_axis>` and `<unit meter="1" name="metre"/>` in its asset block. Unlike glTF, OBJ and STL, COLLADA states its convention, so an importer that still gets the orientation wrong has no excuse.
The signpost as ASCII PLY with +Z up. PLY has no axis or unit element, so the convention survives only as a header comment that no parser reads: the reason scan data so often arrives rotated.
The signpost as USDZ with `upAxis = "Z"` and `metersPerUnit = 1` in the stage metadata. USD is the only format in this group that declares BOTH the axis and the scale, which is exactly why it is the one AR pipelines standardised on.
Real deterministic FBX tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-fbx.
JSON semantic reference for the FBX tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-fbx-reference.
Real deterministic 3DS tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-3ds.
JSON semantic reference for the 3DS tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-3ds-reference.
Real deterministic AMF tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-amf.
JSON semantic reference for the AMF tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-amf-reference.
Real deterministic LWO tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-lwo.
JSON semantic reference for the LWO tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-lwo-reference.
Real deterministic VTK tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-vtk.
JSON semantic reference for the VTK tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-vtk-reference.
Real deterministic VOX source with four occupied voxel coordinates, palette indices, and unit occupied-coordinate bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-vox.
JSON semantic reference for the VOX fixture, publishing occupied coordinates, palette indices, empty face topology, bounds, and the voxel contract. Stable P8 artifact p8-convert-model-vox-reference.
Real deterministic DRC tetrahedron source with four vertices, four triangular faces, and unit bounds for Convert v2 import coverage. Stable P8 artifact p8-convert-model-drc.
JSON semantic reference for the DRC tetrahedron, publishing vertex order, face indices, bounds, and the closed-mesh contract. Stable P8 artifact p8-convert-model-drc-reference.
The Novus Sans Sample demonstration typeface as TrueType (glyf outlines): one member of a TTF/OTF/WOFF/WOFF2 conversion set built from scratch with fontTools. Original and free to use; a fixture for testing font loading, subsetting, and conversion.
The Novus Sans Sample demonstration typeface as WOFF (TrueType-flavoured web font): one member of a TTF/OTF/WOFF/WOFF2 conversion set built from scratch with fontTools. Original and free to use; a fixture for testing font loading, subsetting, and conversion.
The Novus Sans Sample demonstration typeface as WOFF2 (Brotli-compressed web font): one member of a TTF/OTF/WOFF/WOFF2 conversion set built from scratch with fontTools. Original and free to use; a fixture for testing font loading, subsetting, and conversion.
The Novus Sans Sample demonstration typeface as OpenType/CFF outlines: one member of a TTF/OTF/WOFF/WOFF2 conversion set built from scratch with fontTools. Original and free to use; a fixture for testing font loading, subsetting, and conversion.
A fixed-width (monospace) demonstration typeface where every glyph shares the same advance width: a fixture for testing monospace detection, code-editor rendering, and column alignment. Original and free to use.
An icon font with six simple pictographs (star, heart, check, arrow, circle, square) mapped to the Private Use Area (U+E000–U+E005), with the glyph map documented in the spec. A fixture for testing icon-font loading, @font-face, and PUA handling.
A hand-written 5×7 BDF bitmap font covering the digits, a colon, and space: the classic X11 bitmap-font format, in plain text. A fixture for testing BDF parsers, bitmap-font converters, and retro/embedded rendering.
A TrueType Collection (.ttc) bundling two fonts (the Novus Mono Sample and Novus Icons) in a single container file. A fixture for testing TTC parsing, font-index selection, and collection-aware loaders.
A tiny demonstration font declaring a Weight (wght) fvar axis, for VF-aware loaders and specimen tools.
Demonstration variable-font SAMPLE with a wght axis for variable-font loaders.
WOFF2 wrapper of the Novus variable SAMPLE for @font-face tests.
Static specimen labelled as a regular variable-font instance for instance-picker UIs.
Static specimen labelled as a boldish variable-font instance for instance-picker UIs.
Variable-font instance note SAMPLE #1.
Variable-font instance note SAMPLE #2.
Variable-font instance note SAMPLE #3.
Variable-font instance note SAMPLE #4.
A true variable font: three interpolating masters compiled through fontTools varLib, so the wght axis carries real gvar and HVAR deltas rather than an fvar record over static outlines. Five named instances and a STAT table with a Regular-to-Bold linked value. Original typeface, free to use.
The wght variable font wrapped as WOFF: the same fvar/gvar payload in the web container, for testing that a compressor or a CDN pipeline preserves variation data. Original typeface, free to use.
The wght variable font wrapped as WOFF2: the same fvar/gvar payload in the web container, for testing that a compressor or a CDN pipeline preserves variation data. Original typeface, free to use.
A single-axis variable font on the registered wdth axis, built from 3 interpolating masters so the deltas are real: advance widths and glyph boxes narrow and widen with the axis. Named instances and a STAT table are included. Original typeface, free to use.
A single-axis variable font on the registered slnt axis, built from 2 interpolating masters so the deltas are real: the whole face shears forward as slnt goes negative, with the axis maximum equal to the default. Named instances and a STAT table are included. Original typeface, free to use.
A single-axis variable font on the registered opsz axis, built from 3 interpolating masters so the deltas are real: stems thicken and tracking opens at small optical sizes and reverse at display sizes. Named instances and a STAT table are included. Original typeface, free to use.
A two-axis variable font (weight by width) built from seven masters, with all nine named instances from Condensed Regular to Expanded Black and a two-axis STAT table. For testing instance pickers, axis sliders, and CSS font-variation-settings with more than one axis in play. Original typeface, free to use.
The two-axis variable font as WOFF2: the container a real site would ship. For testing that variation tables survive Brotli packing and that a two-axis slider still works after decompression. Original typeface, free to use.
All four registered axes in one face (weight, width, slant and optical size) from eight axis-extreme masters. The font a variation UI should be tested against before it meets a real four-axis release. Original typeface, free to use.
The four-axis variable font as WOFF2. For testing web font loaders and CSS font-variation-settings against a face with more axes than a typical release. Original typeface, free to use.
A variable font carrying one registered axis and one custom axis. Custom tags are all-uppercase by specification and must be looked up by name rather than assumed, so this is the fixture for a UI that hardcodes wght/wdth/slnt/opsz and silently drops everything else. Original typeface, free to use.
The same three masters as the plain wght variable font, plus an avar table that warps the axis so most of the weight change happens in the first third of the slider. Diff it against its no-avar twin: identical outlines, different rendering at every intermediate value. Original typeface, free to use.
The control half of the avar pair: identical masters and identical gvar deltas, with no avar table, so the axis maps linearly. Any rendering difference against its avar twin is the avar table and nothing else. Original typeface, free to use.
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.
A variable font whose outlines are CFF2 rather than glyf, so the variation deltas live inside blended charstrings and there is no gvar table at all. The case that breaks tools which assume every variable font is TrueType-flavoured. Original typeface, free to use.
The two-axis font with its width axis pinned to Condensed and its weight axis left live: the shipping shape for a site that wants one width but the whole weight range. For testing that a loader reads the reduced fvar rather than the original axis list. Original typeface, free to use.
A real static instance cut from the wght variable font at 300. Outlines interpolated once and baked, fvar and gvar stripped, usWeightClass set to match. For testing static-versus-variable fallback paths and family/style grouping. Original typeface, free to use.
A real static instance cut from the wght variable font at 400. Outlines interpolated once and baked, fvar and gvar stripped, usWeightClass set to match. For testing static-versus-variable fallback paths and family/style grouping. Original typeface, free to use.
A real static instance cut from the wght variable font at 500. Outlines interpolated once and baked, fvar and gvar stripped, usWeightClass set to match. For testing static-versus-variable fallback paths and family/style grouping. Original typeface, free to use.
A real static instance cut from the wght variable font at 700. Outlines interpolated once and baked, fvar and gvar stripped, usWeightClass set to match. For testing static-versus-variable fallback paths and family/style grouping. Original typeface, free to use.
A real static instance cut from the wght variable font at 900. Outlines interpolated once and baked, fvar and gvar stripped, usWeightClass set to match. For testing static-versus-variable fallback paths and family/style grouping. Original typeface, free to use.
A two-axis instance baked out of the weight-by-width variable font, with both usWeightClass and usWidthClass set to match. For testing that a family grouper reads width from OS/2 rather than guessing it from the style name. Original typeface, free to use.
A COLR version 0 colour font: three Private Use Area icons, each drawn as two layer glyphs that index CPAL palette entries, with ordinary monochrome glyf outlines underneath as the fallback. The baseline colour-font case that every modern browser supports. Original typeface, free to use.
The COLR v0 colour font as WOFF2, for testing that a web-font pipeline keeps COLR and CPAL rather than stripping them as unknown tables. Original typeface, free to use.
A COLR version 1 colour font built as a real paint graph: a linear gradient with pad extend, a radial gradient with reflect, a repeating three-stop gradient, and a solid paint with fractional alpha. For testing gradient support, extend-mode handling, and the v1-to-v0 fallback path. Original typeface, free to use.
The COLR v1 gradient font as WOFF2: the shape a site would actually serve. For testing that gradient paint graphs survive web-font compression intact. Original typeface, free to use.
A colour font carrying four CPAL palettes with name-table labels and palette-type flags, two of them marked usable with a light or a dark background. For testing palette pickers, the CSS font-palette property, and renderers that only ever read palette zero. Original typeface, free to use.
COLR and CPAL over CFF rather than glyf outlines. COLR is outline-agnostic by specification, but plenty of tooling assumes colour fonts are TrueType-flavoured: this is the file that finds out. Original typeface, free to use.
An sbix colour font: Apple's embedded-bitmap format, one 128 ppem PNG strike per icon glyph, with vector glyf outlines kept underneath for renderers that ignore sbix. For testing bitmap-strike extraction and the strike-versus-outline decision. Original typeface, free to use.
A CBDT/CBLC colour font: the embedded-bitmap format Android and Chrome use for colour emoji, here with a 64 ppem 32-bit strike in image format 17. For testing bitmap-strike parsers and the CBDT-versus-sbix branch in a colour-font pipeline. Original typeface, free to use.
An OpenType-SVG colour font: one inline SVG document per icon glyph, each with its own gradient, plus glyf outlines for renderers with no SVG support. For testing the fourth colour-font path and how a rasteriser handles vector colour it has to parse rather than paint. Original typeface, free to use.
Standard and discretionary ligature substitutions in a real GSUB table: four liga ligatures including the three-glyph ffi, and two dlig ligatures that must stay off unless asked for. Each ligature's advance is the sum of its parts minus a documented tuck, so a shaping result is checkable by measuring. Original typeface, free to use.
Eighteen kerning pairs published as a GPOS pair-positioning lookup, with no legacy kern table present. Pair it with its kern-table twin to find out which table your layout engine is actually reading. Original typeface, free to use.
The same eighteen kerning pairs, this time in a format-0 legacy kern table with no GPOS at all. Modern shapers ignore kern when GPOS exists and some ignore it entirely, so this twin is how you tell which code path produced a given measurement. Original typeface, free to use.
Contextual alternate substitution that fires on doubled letters: the second letter of aa, ee, oo, nn, ss and tt is replaced by an alternate carrying a visible baseline underscore, so a shaping result can be read straight off the page instead of out of a debug log. calt is on by default, which makes it a good test of whether a renderer applies default features at all. Original typeface, free to use.
A full 26-glyph small-capital set reachable through smcp from lowercase and c2sc from capitals. Because the lowercase of this face is unicase, the small caps sit at a third, measurable height: 560 design units against 500 for lowercase and 700 for capitals, so a failed substitution shows up as a height rather than as a subtle shape difference. Original typeface, free to use.
Three stylistic sets, each with a human-readable name published through FeatureParams in the name table: the metadata a font menu needs to show 'Squared G and R' instead of 'ss01'. For testing feature-name discovery as much as the substitution itself. Original typeface, free to use.
All four figure features over one digit set: the default is proportional lining, tnum flattens every digit to 620 units for column alignment, pnum restores the proportional widths, and onum drops five digits below the baseline and raises two above the x-height. The measurable case for testing font-variant-numeric. Original typeface, free to use.
A real frac implementation as a chaining contextual substitution: the slash becomes a fraction slash, the digit before it becomes a numerator and the digit after becomes a denominator, with numr and dnom also reachable on their own. Coverage is deliberately limited to single-digit fractions, which is stated in the specs so a test can assert the boundary. Original typeface, free to use.
Mark-to-base and mark-to-mark positioning with a real GDEF glyph-class definition: three zero-width combining accents attach to ten base letters at documented anchors, and stacking a second mark uses the mkmk anchor. For testing diacritic placement without needing a full Unicode face. Original typeface, free to use.
An aalt feature that aggregates every alternate reachable through the stylistic sets and the small-cap set, which is what a glyph-palette UI reads to offer 'other forms of this character'. For testing alternate-picker panels rather than automatic shaping. Original typeface, free to use.
Language-specific substitution through locl: tagging text as Turkish swaps the i, tagging it as Romanian swaps the S, and untagged text gets neither. The fixture for finding out whether your pipeline propagates a language tag from the document all the way to the shaper. Original typeface, free to use.
Every feature this family defines in one face: ligatures, kerning, contextual alternates, small caps, three stylistic sets, four figure features, fractions, mark attachment, aalt and locl. The single font to point a feature-discovery UI at. Original typeface, free to use.
The all-features font as WOFF2, for testing that a web-font build step preserves GSUB, GPOS and GDEF instead of subsetting the layout tables away by default. Original typeface, free to use.
The control for the all-features font: the same glyph set and the same metrics with no layout tables at all, so the alternates exist in the font but nothing can reach them. Any difference you measure against the full twin is the layout tables and nothing else. Original typeface, free to use.
The control case: all three vertical-metric families carry the same numbers, so every platform computes the same 1.0 em default line height. Measure this first, then measure its disagreeing twin: the difference is entirely the metrics. Original typeface, free to use.
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.
Byte-for-byte the same conflicting metrics as the disagree fixture, with one bit changed: fsSelection bit 7, USE_TYPO_METRICS. A conforming renderer must now prefer the OS/2 typo family and produce a 1.0 em line box. One bit, a 40 percent difference in leading. Original typeface, free to use.
Ascender and descender identical to the agreeing fixture, with 250 units of external leading declared in both lineGap fields. Renderers differ on whether line gap belongs inside the line box, above it, or split: this is the file that shows which one yours does. 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.
A horizontal Latin face that also carries vhea and vmtx, so vertical-layout code has something small and predictable to run against: every glyph advances 1000 units downward with a 250-unit top side bearing. For testing writing-mode support and metric-table selection without needing a CJK font. Original typeface, free to use.
The same design on a 1000-unit em square: the decimal grid PostScript and most web fonts use. Diff it against its twin at the other unitsPerEm to catch code that hardcodes 1000 or 2048 instead of reading head.unitsPerEm, and to see where rounding shows up. Original typeface, free to use.
The same design on a 2048-unit em square: the power-of-two grid classic TrueType fonts use. Diff it against its twin at the other unitsPerEm to catch code that hardcodes 1000 or 2048 instead of reading head.unitsPerEm, and to see where rounding shows up. 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 complete face the rest of the subset set is cut from: the whole glyph repertoire with ligatures, kerning, contextual alternates, small caps, stylistic sets, figures, fractions, marks and localised forms intact. Measure it, then measure the cuts. Original typeface, free to use.
The full face as WOFF2: the honest baseline for a subsetting benchmark, since comparing a subsetted WOFF2 against an unsubsetted TTF measures Brotli rather than the subsetter. Original typeface, free to use.
The full face subset to U+0020-U+007E (printable ASCII): the range a Latin-only page actually needs. Layout features are kept, so lookups whose glyphs were removed are the ones you can watch disappear. Original typeface, free to use.
The latin basic subset in the container a site would serve, so a size comparison against the full WOFF2 measures the subset rather than the compressor. Original typeface, free to use.
The full face subset to the 8 codepoints of the string NOVUS 07: the extreme case a headline-only web font gets cut down to. Layout features are kept, so lookups whose glyphs were removed are the ones you can watch disappear. Original typeface, free to use.
The headline subset in the container a site would serve, so a size comparison against the full WOFF2 measures the subset rather than the compressor. Original typeface, free to use.
The full face subset to U+0030-U+0039 (digits only): a numeric-display cut, the shape a dashboard font ends up. Layout features are kept, so lookups whose glyphs were removed are the ones you can watch disappear. Original typeface, free to use.
The digits subset in the container a site would serve, so a size comparison against the full WOFF2 measures the subset rather than the compressor. Original typeface, free to use.
A subset cut to just the characters the kerning, ligature, small-cap and figure probes need, keeping every OpenType layout feature whose glyphs survived. Half of a pair whose only difference is the layout tables: the pair that shows what a default subsetter setting silently costs you. 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.
The uncompressed TrueType (glyf) source for this container set. Every WOFF and WOFF2 file in the group is packed from exactly these bytes, so a compression comparison is measuring the container and nothing else. Original typeface, free to use.
The same TrueType (glyf) face in a WOFF container, 49 percent of the raw sfnt size. Compare it against the other three containers in this group to see how much of a web font's weight is the format and how much is the design. Original typeface, free to use.
The same TrueType (glyf) face in a WOFF2 container, 33 percent of the raw sfnt size. Compare it against the other three containers in this group to see how much of a web font's weight is the format and how much is the design. Original typeface, free to use.
The uncompressed CFF (Type 2) source for this container set. Every WOFF and WOFF2 file in the group is packed from exactly these bytes, so a compression comparison is measuring the container and nothing else. Original typeface, free to use.
The same CFF (Type 2) face in a WOFF container, 55 percent of the raw sfnt size. Compare it against the other three containers in this group to see how much of a web font's weight is the format and how much is the design. Original typeface, free to use.
The same CFF (Type 2) face in a WOFF2 container, 45 percent of the raw sfnt size. Compare it against the other three containers in this group to see how much of a web font's weight is the format and how much is the design. Original typeface, free to use.
A WOFF file carrying the optional extended-metadata block from the WOFF specification: vendor, credits, description and licence as XML alongside the font, outside the sfnt tables. Most converters drop it silently; this is the file that proves whether yours does. Original typeface, free to use.
A WOFF2 file carrying the optional extended-metadata block from the WOFF specification: vendor, credits, description and licence as XML alongside the font, outside the sfnt tables. Most converters drop it silently; this is the file that proves whether yours does. Original typeface, free to use.
One design in TrueType outlines: quadratic contours in a glyf table with a loca index. Its CFF twin carries the same design in cubic charstrings, so converting one and diffing against the other tests an outline converter rather than a whole font pipeline. Original typeface, free to use.
The same design in CFF outlines: cubic Type 2 charstrings with no glyf and no loca. The half of the pair that catches code assuming every OpenType font is TrueType-flavoured. Original typeface, free to use.
Four precomposed accented letters built the way real fonts build them, as composite glyphs referencing a base letter and a combining mark with a translation. For testing component resolution, nested-glyph handling, and subsetters that must keep a component's base glyph alive. Original typeface, free to use.
The same four accented letters flattened into simple glyphs with the mark contours copied in. Rendering is identical to the composite twin; the file size, the subsetting behaviour and the hinting story are not. 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.
A TrueType Collection holding three faces of one family with identical tables stored once and referenced by offset from each face's table directory. For testing face-index selection, collection-aware loaders, and extractors that must not assume each face owns its tables. Original typeface, free to use.
The same three faces in a collection that stores every table separately, so each face's directory points at its own copy. Identical rendering, a bigger file: the reference that makes the shared-table saving measurable rather than assumed. Original typeface, free to use.
A collection whose members are themselves variable fonts, each with its own axis, fvar, gvar and STAT. The case that breaks loaders which handle collections or variations but never both at once. 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.
A short H.264 test clip in an MP4 container (yuv420p, faststart): the most widely supported web and mobile video format. Video-only and tiny; for testing players, thumbnailers, and MP4→other conversion.
The same clip as WebM/VP9: the royalty-free web video format. Video-only; for testing HTML5 <video>, VP9 decoding, and WebM conversion.
The clip in a Matroska (MKV) container with H.264 video: the flexible open container used for rich multi-track media. For testing MKV demuxing and remux/conversion.
The clip in a QuickTime (MOV) container with H.264 video: Apple's container, common from cameras and editors. For testing MOV parsing and MOV→MP4 conversion.
The clip as Motion-JPEG in a classic AVI (RIFF) container: every frame an independent JPEG. For testing legacy AVI readers, MJPEG decoding, and AVI→modern-codec conversion.
The clip as Ogg Theora: a fully open, royalty-free format. Browser-playable; for testing Theora decoding and Ogg video conversion.
The clip as MPEG-1 in an MPEG program stream (.mpg): the VCD-era format. For testing legacy MPEG demuxing and conversion to modern codecs.
The clip as M4V: Apple's MP4 variant used by iTunes. Browser-playable; for testing M4V handling and M4V↔MP4 conversion.
The clip as 3GP: the 3GPP mobile container from the feature-phone era. For testing 3GP demuxing and conversion.
The clip as an MPEG transport stream (.ts): the container behind HLS streaming and broadcast. For testing TS demuxing and HLS tooling.
The clip as Flash Video (.flv) with H.264: the legacy web-streaming container. For testing FLV demuxing and conversion to MP4.
The clip as Windows Media Video (WMV2 in an ASF container): Microsoft's legacy video format. For testing WMV decoding and conversion to open formats.
The clip as DivX-style MPEG-4 ASP in an AVI container: the codec that defined early desktop video. For testing MPEG-4 Part 2 decoding and AVI conversion.
A ZIP bundling the MP4 and WebM test clips with a README: a 'video archive' for testing pipelines that unpack an archive and then transcode its contents. Stored (not re-compressed), since the clips are already compressed.
A five-second clip that flashes white and plays a 1 kHz beep on every whole second: the first clip in the library WITH an audio track. A direct fixture for measuring and correcting audio/video sync (lip-sync) offset.
Standard SMPTE-style colour bars with a 1 kHz reference tone: the classic broadcast test pattern. A fixture for calibrating colour, testing decoders, and verifying audio alongside a known video signal.
A six-second countdown (5→0) with a sweeping second-arc, a burned-in SS:FF timecode, and a beep on each second: a slate/leader fixture for testing timecode reading, frame-accurate seeking, and sync.
A portrait 9:16 (270×480) clip with a vertically-moving marker: the aspect ratio of phone and short-form video. A fixture for testing vertical-video handling, orientation, and letterboxing in players and thumbnailers.
A 60 frames-per-second clip with a smoothly sweeping marker: double the usual frame rate. A fixture for testing high-frame-rate playback, frame-rate detection, and fps conversion (60→30 decimation).
A clip with a soft (muxed, toggleable) SRT subtitle track in a Matroska container: the subtitles are a separate stream, not burned in. A fixture for testing subtitle extraction, rendering, and toggling.
The same clip with a soft subtitle track as MP4 mov_text (the MP4-native subtitle format): the format twin of the MKV/SRT file, for testing subtitle handling across containers.
A screen-recording-style clip of a mock terminal: a window with traffic-light buttons and build output typing out line by line with a blinking cursor. A fixture for testing screen-capture pipelines, UI-motion thumbnails, and text-in-video OCR.
A short H.264 clip with an abrupt mid-point colour scene cut, for scene-detection and keyframe tooling.
Motion, then a one-second frozen segment, then motion again, for freeze detection and VFR edge cases.
A clip with a short pure-black insert, for black-frame detectors and QC tools.
Video with a SAMPLE caption burned into the pixels (not a soft subtitle track), for OCR/caption-burn detection.
Short strobe/flash pattern for photosensitivity QC and flash-frame detectors.
Content framed with black letterbox bars, for autocrop and aspect-ratio tools.
A short colour-bar test pattern clip, for colour pipeline and player QC.
On-screen countdown digits burned into frames, for OCR and slate detection.
Short clip with a SAMPLE soft subtitle track (mov_text): twin to the hard-burned caption.
Hard-burned caption twin of the soft-sub clip, for burn-in detection and OCR.
Companion SRT for the soft-sub MP4: same SAMPLE cue timings.
Companion VTT for the soft-sub MP4: same SAMPLE cue timings.
Short 9:16 SAMPLE clip at 270x480 for aspect-ratio and social-crop tooling.
Short 1:1 SAMPLE clip at 270x270 for aspect-ratio and social-crop tooling.
Short 16:9 SAMPLE clip at 480x270 for aspect-ratio and social-crop tooling.
SAMPLE clip tagged/encoded for 90° rotation, for orientation-aware players.
SAMPLE clip tagged/encoded for 180° rotation, for orientation-aware players.
SAMPLE clip tagged/encoded for 270° rotation, for orientation-aware players.
Video muxed with a 440 Hz sine tone, for A/V container and audio-track tests.
Video muxed with an 880 Hz tone: frequency twin for audio pipeline tests.
SAMPLE clip with audio delayed ~100 ms, for A/V sync detection tools.
SAMPLE clip with audio delayed ~250 ms, for A/V sync detection tools.
SAMPLE clip with audio delayed ~500 ms, for A/V sync detection tools.
SMPTE-ish colour bars with a 1 kHz reference tone: classic QC fixture.
Short white flash frames SAMPLE for colour and flash QC detectors.
Short black flash frames SAMPLE for colour and flash QC detectors.
Short solid red field SAMPLE for colour and flash QC detectors.
Short solid green field SAMPLE for colour and flash QC detectors.
Short solid blue field SAMPLE for colour and flash QC detectors.
Short solid gray field SAMPLE for colour and flash QC detectors.
Content with vertical pillarbox bars, for autocrop tools.
On-screen running timecode burned into frames, for OCR and slate tools.
Short VP9 WebM SAMPLE companion for container conversion tests.
Silent colour-bar twin of the bars+tone clip, for audio-presence detectors.
Additional aspect SAMPLE (360x640) for social and player testing.
Additional aspect SAMPLE (640x360) for social and player testing.
Hard-burned EN SAMPLE caption for OCR language tests.
Hard-burned ES SAMPLE caption for OCR language tests.
Video QC companion SAMPLE (desync-caption.srt) for Wave G suites.
Video QC companion SAMPLE (desync-caption.vtt) for Wave G suites.
Video QC companion SAMPLE (portrait-caption.srt) for Wave G suites.
Video QC companion SAMPLE (portrait-caption.vtt) for Wave G suites.
Video QC companion SAMPLE (square-caption.srt) for Wave G suites.
Video QC companion SAMPLE (square-caption.vtt) for Wave G suites.
Video QC companion SAMPLE (av-sync-notes.json) for Wave G suites.
Video QC companion SAMPLE (video-qc-checklist.txt) for Wave G suites.
Broadcast closed captions as Scenarist SCC: SMPTE timecodes followed by hexadecimal CEA-608 byte pairs, with odd parity set on every byte as the standard requires. Uses pop-on mode: RCL to load, ENM to clear non-displayed memory, a preamble address code for row 15, the character pairs, then EOC to display. This is the fixture that exposes decoders which treat captions as text: the parity bits, the two-byte control codes and the frame-accurate timecodes all have to be handled.
Timed text as DFXP, byte-for-byte a TTML document, just under the extension Netflix, Adobe and older captioning tool-chains still use. Same tt root, same head/body/div/p structure, same styling and region attributes. It exists to check that a caption parser dispatches on document content rather than on the file extension: a parser that accepts .ttml but rejects an identical .dfxp is exactly the bug this catches.
The same five cues as a plain JSON array with float second timings: the shape most caption pipelines use internally between parsing one format and writing another. Handy as the expected intermediate when testing a converter, since it removes timestamp-formatting differences from the comparison.
Advanced SubStation Alpha using the features that distinguish it from SubRip: per-syllable \k karaoke timings in centiseconds, a full V4+ style definition with primary and secondary colours, and an \an override that repositions a line. Converting this to SRT necessarily loses all of it, which makes it a good test of whether a converter warns about that or drops it silently.
An HLS master playlist declaring a three-rung bitrate ladder plus a subtitle rendition group, with the CODECS, RESOLUTION and FRAME-RATE attributes a player needs to choose a rung before fetching anything. Served inline with permissive CORS from /files/stream/, so a player on another origin can load it directly. This is a manifest-parsing fixture: it describes the ladder rather than shipping its segments.
A VOD media playlist in CMAF form: an EXT-X-MAP initialisation segment followed by four fragmented-MP4 segments and an explicit ENDLIST. The final segment is deliberately short, as a real encode's last segment usually is. Tests target-duration handling, init-segment fetching, and correct total-duration arithmetic. A manifest-parsing fixture: the segments themselves ship with the streaming phase.
Every segment is a byte range of one backing file rather than a separate download, which is how low-overhead VOD packaging avoids thousands of small objects. The /files/stream/ headers expose Content-Range and Accept-Ranges cross-origin precisely so a player can do this from another origin. Tests Range request construction and offset arithmetic.
A DASH manifest with separate video and audio adaptation sets, three video representations, and $RepresentationID$/$Number$ segment-template addressing: the standard VOD packaging shape. Served inline as application/dash+xml with permissive CORS, so dash.js can load it cross-origin. A manifest-parsing fixture: it describes segment URLs rather than shipping the segments.
Three DASH periods (content, an ad break, then content again), each with its own initialisation segment. Period boundaries are where players most often break: the decoder must be reset, the buffer cannot span the discontinuity, and rendition selection restarts. Pairs with the VMAP and SCTE-35 fixtures, which describe the same break from the ad-signalling side.
A machine-readable index of all 67 timed-text, streaming-manifest and ad-signalling fixtures in this wave, with id, format, path and byte size for each. Useful as a work-list when running a parser across the whole suite, and as a manifest to diff against after regenerating.
Enhanced LRC with per-word timings in angle brackets alongside the usual per-line timestamps: the format karaoke and lyric-sync apps consume. Includes the standard metadata tags, an offset field, and a final empty timestamp that clears the display. Simple LRC parsers read only the line timings and silently render the word markers as visible text.
TTML using the features broadcast caption profiles rely on: two layout regions, named styles including a text outline, a declared frame rate and media time base, and spans nested two deep so styles cascade. Converting this to SubRip necessarily flattens all of it. Tests whether a TTML implementation resolves style inheritance or only reads the leaf text.
The subtitle rendition the master playlist references through EXT-X-MEDIA. Captions in HLS are segmented like media: each segment is a small WebVTT file covering its own time window, carrying X-TIMESTAMP-MAP to align with the MPEG-TS clock. Completes the master playlist's declared rendition group so a player can resolve the whole tree.
A media playlist with a mid-roll spliced in: EXT-X-CUE-OUT opens the break, EXT-X-DISCONTINUITY marks each boundary, and a fresh EXT-X-MAP re-initialises the decoder on both sides. This is what a packager produces from the SCTE-35 splice_insert fixture in this wave. Discontinuities are where players most often stall, because the timeline and the decoder both have to be reset.
A Low-Latency HLS playlist: half-second EXT-X-PART fragments published ahead of their parent segment, a preload hint for the part still being written, and EXT-X-SERVER-CONTROL advertising blocking playlist reload. There is deliberately no ENDLIST, because this is a live playlist. Tests parsers against the LL-HLS tags, which are frequently unimplemented and must at minimum be ignored safely.
An I-frame-only playlist: each entry is a byte range covering a single keyframe inside the media file, which is how players render scrub previews and fast-forward without decoding every frame. Declared in a master playlist via EXT-X-I-FRAME-STREAM-INF. Tests that a parser distinguishes these from normal media playlists, playing one as ordinary media produces a stuttering slideshow.
The same content addressed with an explicit SegmentList: every segment URL enumerated rather than derived from a template. Verbose, but it is what older packagers emit and it permits non-uniform segment naming. A DASH client must support both this and SegmentTemplate; the paired template manifest in this group is the direct contrast.
A live DASH manifest: type is dynamic, there is no total duration, and the client must compute which segment is currently available from availabilityStartTime, the wall clock, and the segment duration. Declares a one-minute time-shift buffer and an eight-second presentation delay. The timestamps are fixed so the fixture stays deterministic: a real client will compute a segment number far in the future, which is itself a useful edge case to handle gracefully.
Per-cue timings and text metrics for the shared cue list, as a caption QC tool would export them: start, end, duration, line count and character count. Useful as the expected output when testing a caption analyser, and as a quick way to check reading-rate calculations against known values.
The shared pan-city base plate encoded with H.264 (libx264). The universal baseline. Decodes everywhere, hardware-accelerated on essentially every device shipped this decade. If a pipeline handles only one codec, this is it. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with HEVC (libx265). Roughly half the bitrate of H.264 at the same quality, but patent licensing kept it out of browsers. Tagged hvc1 rather than hev1, which is what Safari and QuickTime require: the wrong tag is a common cause of a file that plays everywhere except on Apple hardware. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with AV1 (libaom-av1). Royalty-free and now decoded by every current browser. Encoding is far slower than H.264, which is why this fixture uses a fast preset; the bitstream is standard regardless. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with VP9 (libvpx-vp9). Google's royalty-free predecessor to AV1, and still the workhorse of WebM delivery. Plays natively in every major browser. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with VP8 (libvpx). The first WebM codec, now legacy but still what MediaRecorder emits by default in several browsers, so it turns up in user-generated uploads far more often than its age suggests. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with Theora (libtheora). The original open web video codec, in an Ogg container. Largely historical, but still the fallback path in older HTML5 players and a good test of whether a pipeline's format detection is driven by content rather than by a hardcoded list. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with MPEG-4 Part 2 (DivX/Xvid-compatible). The DivX/Xvid era, tagged XVID in an AVI. Predates H.264 and is still what a great deal of archived material is stored as, so ingest pipelines meet it constantly. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with MPEG-2 (mpeg2video). The DVD and broadcast codec. Intra-heavy and inefficient by modern standards, but it is the format broadcast and archive workflows are still built around. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with MJPEG. Every frame is an independent JPEG, with no inter-frame prediction at all. Large, but it makes any frame a clean cut point, which is why cameras and capture cards still emit it. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with FFV1 level 3 (lossless). Mathematically lossless: decoding reproduces the source pixels bit for bit. Used for archival preservation, and the right reference when you need to prove a processing step, not a codec, caused a change. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with FFmpeg prores_ks, profile 0 (proxy). An intra-only 10-bit 4:2:2 mezzanine written by FFmpeg's prores_ks encoder: the interchange shape editorial workflows expect. Described as ProRes-COMPATIBLE deliberately: this is FFmpeg's independent implementation, not Apple's encoder. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with WMV2. Windows Media in an ASF container. Long obsolete, but it is what a large amount of corporate and archival material was encoded as, and few non-FFmpeg tools read it. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with FLV1 / Sorenson Spark. The Flash video codec. Entirely historical for delivery, but FLV files persist throughout media archives and legacy CMS exports. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
The shared pan-city base plate encoded with MS-MPEG-4 v3 (msmpeg4v3). Microsoft's non-standard MPEG-4 Part 2 variant: the 'DivX 3' bitstream. Deliberately incompatible with the standard decoder, which makes it a sharp test of whether a pipeline identifies codecs from the bitstream or from the FourCC. Every clip in this group carries the identical picture, so a decoder-support matrix built from them isolates the codec as the only variable.
One H.264 elementary stream wrapped in MP4 (ISO BMFF). Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. The ISO base media format, and the default for web delivery. Supports faststart, which moves the index to the front so playback can begin before the file has finished downloading.
One H.264 elementary stream wrapped in Matroska. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. The most permissive container in common use: any codec, unlimited tracks, chapters, attachments. Not natively playable in Safari, which is its main practical limitation.
One H.264 elementary stream wrapped in QuickTime. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. Apple's container, and the direct ancestor of MP4: the two share the same atom structure, which is why remuxing between them is nearly free.
One H.264 elementary stream wrapped in AVI. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. Microsoft's 1992 container. No B-frame timestamp support and a 4 GB practical limit, but enormous amounts of archived material still live in it.
One H.264 elementary stream wrapped in MPEG Transport Stream. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. The broadcast and HLS-segment container. Fixed 188-byte packets and no global index, so it can be cut at any packet boundary and still decode, which is exactly why streaming uses it.
One H.264 elementary stream wrapped in M4V. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. MP4 under Apple's alternative extension. Byte-identical structure; the extension exists purely so iTunes could distinguish video, and it is a good test of extension-driven format detection.
One H.264 elementary stream wrapped in 3GP. Every file in this group was produced from the SAME encode with a stream copy, so the compressed video bytes are identical and the container is genuinely the only difference. The mobile profile of MP4, from the feature-phone era. Still emitted by some Android capture paths, so it turns up in user uploads.
8-bit 4:2:0 HEVC. The universal delivery format. Chroma is stored at quarter resolution, which is invisible on photographic content and very visible on saturated text and thin graphic edges. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.
8-bit 4:2:2 HEVC. Chroma at half horizontal resolution: the broadcast and mezzanine standard. Survives one round of chroma keying and colour correction far better than 4:2:0. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.
8-bit 4:4:4 HEVC. No chroma subsampling at all. Necessary for screen content and graphics, and the only format where coloured text stays clean, but unsupported by most hardware decoders. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.
10-bit 4:2:0 HEVC. Ten bits per component gives 1024 levels instead of 256, which is what removes banding from smooth gradients. Now the norm for HDR and for high-quality SDR encodes. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.
10-bit 4:2:2 HEVC. The professional acquisition and mezzanine format, enough chroma for keying and enough bit depth for grading. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.
10-bit 4:4:4 HEVC. Full chroma at 10 bits. Effectively an intermediate format only; almost nothing decodes it in hardware. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.
12-bit 4:2:0 HEVC. Twelve bits, at the top of what HEVC's Main 12 profile supports. Cinema and scientific capture; included as the limit case that finds decoders which silently truncate to 8 bits. Shipped in Matroska rather than MP4 on purpose: an exotic pixel format in an .mp4 would be advertised as browser-playable and then fail to decode. Every clip in this group is the same picture, so the pixel format is the only variable.
Every frame is an I-frame, so any frame is an independent cut point. Much larger, and the shape editing and frame-accurate seeking want. Same picture and same codec as every other clip in this group; only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
A keyframe every 8 frames with scene-cut detection disabled, so the GOP length is exactly what it says. Short GOPs cost bitrate but bound seek latency: the trade-off streaming packagers make explicitly. Same picture and same codec as every other clip in this group; only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
One keyframe per second: the delivery default, and the setting that determines HLS/DASH segment boundaries, since a segment must start on a keyframe. Same picture and same codec as every other clip in this group; only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
Exactly one keyframe, at the start. Maximally efficient and nearly unseekable: a player must decode from frame zero to reach any position, which is what makes long-GOP archives painful to scrub. Same picture and same codec as every other clip in this group; only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
I and P frames only. Required by some low-latency and legacy decoders, and it removes the reordering that makes decode order differ from display order. Same picture and same codec as every other clip in this group; only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
Eight consecutive B-frames with a B-pyramid, so decode order and display order diverge sharply and DTS runs well behind PTS. The case that breaks naive timestamp handling and any code that assumes frames arrive in display order. Same picture and same codec as every other clip in this group; only the GOP and frame-type structure differ, so the effect on size and seekability is directly attributable.
The moov index is relocated to the front of the file, so a player can begin playback after the first few kilobytes. Required for progressive download to work at all. Byte-for-byte the same encode as its twin in this group; only the atom order differs, which is why comparing the two is the clean way to demonstrate the effect.
The default MP4 layout, with the index written last. A progressive-download player must fetch the entire file before it can start: the classic 'video buffers forever' bug, and invisible unless you look at the atom order. Byte-for-byte the same encode as its twin in this group; only the atom order differs, which is why comparing the two is the clean way to demonstrate the effect.
Fragmented MP4: an empty moov followed by independent moof/mdat fragment pairs, rather than one monolithic index. This is what CMAF streaming actually delivers, and what makes a segment playable without the rest of the file. Parsers written against progressive MP4 frequently fail here, because there is no sample table to read up front.
Whole frames, captured and displayed at once: the reference for this group and how essentially all modern video is shot. In Matroska rather than MP4 so the catalog renders a poster instead of advertising an inline player, combing artefacts are best judged from a still anyway.
Alternate lines carry alternate instants, with the top field displayed first: the HD broadcast convention. Shown progressively it combs on every moving edge. In Matroska rather than MP4 so the catalog renders a poster instead of advertising an inline player, combing artefacts are best judged from a still anyway.
The same interlacing with the opposite field order, the DV and SD convention. Deinterlacing with the wrong field order makes motion jitter backwards: a subtle, very common bug that this pair makes reproducible. In Matroska rather than MP4 so the catalog renders a poster instead of advertising an inline player, combing artefacts are best judged from a still anyway.
A 90-degree rotation carried in the container's display matrix while the coded pixels stay in their original orientation, exactly what a phone writes when you record holding it sideways. A player that ignores the matrix shows this 270x480 clip as 480x270, on its side. Thumbnailers and transcoders that read dimensions from the video stream rather than the display matrix get this wrong constantly.
A 180-degree rotation carried in the container's display matrix while the coded pixels stay in their original orientation, exactly what a phone writes when you record holding it sideways. A player that ignores the matrix shows it upside down. Thumbnailers and transcoders that read dimensions from the video stream rather than the display matrix get this wrong constantly.
A 270-degree rotation carried in the container's display matrix while the coded pixels stay in their original orientation, exactly what a phone writes when you record holding it sideways. A player that ignores the matrix shows this 270x480 clip as 480x270, on its side. Thumbnailers and transcoders that read dimensions from the video stream rather than the display matrix get this wrong constantly.
Video with a real per-pixel alpha channel: VP9 yuva420p in WebM, the one alpha path browsers decode natively. Composite it over a page background and the transparency is genuine, not a chroma key. Roughly 90% of each frame is fully transparent. Two traps this file exists to expose. First, auto-alt-ref must be disabled at encode time or libvpx silently drops the alpha plane, producing a valid file with no transparency and no error. Second, WebM stores VP9 alpha in BlockAdditional and signals it with AlphaMode=1, so FFmpeg's NATIVE vp9 decoder reports pix_fmt yuv420p and decodes fully opaque: you must force `-c:v libvpx-vp9` to see the alpha at all. Probing this file with default settings and concluding it has no alpha is the expected mistake.
The same codec and container with NO alpha plane, as the control for the alpha clip in this group. Useful for checking that alpha detection reads the pixel format rather than assuming every WebM is transparent, and for confirming a compositing bug is in the alpha handling rather than in the player.
Two audio tracks with distinct language tags, and English flagged as the default. The two tracks are different pitches (440 Hz and 659 Hz, a perfect fifth apart), so which track a player selected is audible immediately rather than something you have to inspect the file to determine. That is the whole design. Dual-language fixtures that carry the same tone on both tracks cannot distinguish 'switched correctly' from 'ignored the switch', which is the one thing you want to test.
A main audio track plus an audio-description track for blind and low-vision viewers, carrying the `visual_impaired` disposition. The description track is an octave and a bit below the main track, so selecting it is audible. Matroska has exactly one flag for this (there is no separate `descriptions` flag as there is in MP4 and in HTML's own track kinds), so a converter that maps `kind="descriptions"` onto Matroska has to pick this one, and a converter going the other way has to infer it. Both tracks are tagged `eng`, which is the realistic case and the awkward one: a picker that lists tracks by language shows two identical entries, and only the flags tell them apart. Broadcast and streaming compliance regimes increasingly require this track to be present and correctly flagged, and the flags are exactly what a naive `ffmpeg -c copy` remux drops.
A 5.1 track with a different pitch in every channel: an A-major triad across L, R and C, a 60 Hz rumble in the LFE, and two higher tones in the surrounds. Channel order is the standard L, R, C, LFE, Ls, Rs. This makes channel-mapping bugs audible instead of theoretical. Downmix it to stereo and you should hear the triad plus the surrounds; if the centre and the LFE swap (a classic WAV-to-container ordering mistake), the result is unmistakable. Most 5.1 test files play the same content everywhere and cannot detect that at all.
One mono audio track: the shape most phone recordings, voice notes and screen captures actually arrive in, and the one that catches pipelines that hardcode a stereo buffer or index channel 1 without checking that it exists.
A video file with no audio track whatsoever. Pair it with the silent-track file in this group: the two sound identical and are structurally completely different. Code that asks 'does this have audio?' by reading a level meter says no to both. Code that asks the container says no to this one and yes to the other. Whichever answer your pipeline needs, you need both files to know which question it is actually asking.
An audio track that exists, declares stereo, and contains nothing but zero samples. The twin of the no-audio-track file in this group, and the reason that file exists. This is the fixture that catches the false negative in every 'is the audio missing?' check built on a container probe: `ffprobe` reports a healthy AAC stereo track, the duration is right, the bitrate is plausible, and the viewer hears nothing. Detecting it requires decoding and measuring, not inspecting. The language is deliberately `und`, which is what encoders emit when nobody set one: another thing worth being able to reproduce.
A feature track and a commentary track, separated only by the `comment` disposition. The third member of this group's flag set alongside audio description and dual language, and the one that most often ends up auto-selected by mistake: a player that picks the last matching English track rather than the default one starts the film on the commentary.
Four named chapters (Cold Open, Titles, Main Segment, Credits) on two-second boundaries. The clip burns the chapter name and a running timecode into the picture, so the chapter marks can be verified by eye against what the player's chapter menu claims. Matroska stores chapters as a proper EditionEntry structure with nanosecond timestamps and per-language names, and every desktop player exposes them. This is the reference case.
Four named chapters (Cold Open, Titles, Main Segment, Credits) on two-second boundaries. The clip burns the chapter name and a running timecode into the picture, so the chapter marks can be verified by eye against what the player's chapter menu claims. MP4 has no chapter box. FFmpeg writes them as a QuickTime chapter track (a hidden text track referenced by the video track), which QuickTime, VLC and most desktop players read and which browsers ignore completely. Remux this to MKV and back and the chapters usually survive; convert it with a tool that maps streams individually and they usually do not.
The same clip with the chapter marks explicitly removed. The control for this group, and the file that tells you whether a chapter reader returns an empty list or reports the whole-file duration as a single unnamed chapter: both are common, and they are not the same answer.
The XML dialect `mkvmerge` and `mkvpropedit` read to write chapters into a Matroska file without re-muxing it. Timestamps are nanosecond-precision `HH:MM:SS.nnnnnnnnn`, and each ChapterAtom carries a UID that must be stable across edits: the field most hand-written generators omit, which is why re-running them renumbers every chapter.
FFmpeg's own metadata format, and the one used to build the two embedded-chapter files in this group. START and END are integers in the declared TIMEBASE, which is the detail that trips people up: change TIMEBASE and every timestamp silently means something else. This is the exact file the MKV and MP4 chapter fixtures here were built from.
A WebVTT file intended for `<track kind="chapters">` rather than `kind="subtitles"`. Structurally it is an ordinary WebVTT file, which is the point, nothing inside it says 'chapters', so the same bytes behave as captions if the kind attribute is wrong, and the chapter titles are rendered over the video as subtitles. A common and very visible mistake.
The plain-text convention used in video descriptions: `M:SS Title`, one per line, first entry at zero. There is no specification, so every parser guesses, at leading zeros, at `HH:MM:SS` versus `M:SS`, at whether a dash or a dot separates the timestamp from the title. Useful for testing a scraper against the format people actually paste.
Eight container-level metadata fields written into the same eight-second clip, so a metadata reader can be checked against a file whose expected values are published rather than guessed. Every value is obviously sample data. MP4 stores these in an iTunes-style `moov/udta/meta/ilst` atom, with fixed four-character keys. Fields outside that vocabulary (`description` here) are written as freeform `----` atoms that many readers skip, so a tag can be present in the file and invisible to the tool you are testing.
Eight container-level metadata fields written into the same eight-second clip, so a metadata reader can be checked against a file whose expected values are published rather than guessed. Every value is obviously sample data. Matroska stores tags as arbitrary name/value SimpleTags scoped to a target level, so it has no fixed vocabulary and nothing is dropped. The same eight fields as the MP4 in this group: compare the two to see exactly which values survive a cross-container remux and which are quietly lost.
The same clip with every scrap of metadata removed: no tags, no creation time, not even the encoder string FFmpeg normally writes. The control for this group and the baseline for a privacy or scrubbing tool: if your stripper leaves anything this file does not have, it is not stripping enough. Getting to genuinely zero takes `-map_metadata -1` **and** `-fflags +bitexact` placed after the input, as an output option. `-map_metadata -1` alone still leaves the `encoder=Lavf…` tag behind, and putting the bitexact flag before `-i` applies it to the demuxer where it does nothing to the output, which is the usual reason a file someone believes they stripped still names the software that made it. What cannot be removed: `major_brand`, `minor_version` and `compatible_brands`. Probing tools list those alongside the tags, but they are fields of the `ftyp` box that define what the file is, not metadata about it.
Cover art embedded in an MP4 as a still JPEG carrying the `attached_pic` disposition. Note what that means structurally: the artwork is a *second video stream*, not a metadata field. That is the trap. A pipeline that maps 'the video stream' with `-map 0:v` picks up both and produces a file with a stray one-frame track; one that counts video streams to decide whether a file is a video reports two. Both are common, and neither shows up until a file with artwork arrives.
A Matroska attachment: a whole file carried inside the container alongside the media, with its own filename and MIME type. In the wild this is how fonts travel with styled ASS subtitles, so that a rendering machine lacking the typeface still gets the right result. Extract it with `ffmpeg -dump_attachment:t:0 out.txt -i …`. Unlike the MP4 cover art in this group, an attachment is not a media stream: it demuxes as `codec_type=attachment` and has no frames, which is why remuxing to any container without an attachment concept discards it silently. The filename here is deliberately not `cover.jpg`. Matroska's cover-art convention is simply an attachment named `cover.*`, and FFmpeg and most players special-case that name and promote it to an `attached_pic` video stream. So the same bytes attached under two different filenames produce two different stream lists: a genuinely surprising result if you are counting streams to decide what a file contains.
A start timecode of 01:00:00:00: the broadcast convention of beginning programme material at hour one, so that bars, slates and pre-roll can live before it without going negative. FFmpeg writes it as a QuickTime `tmcd` track. The burned-in timecode in the picture deliberately starts at 00:00:00:00 instead. That one-hour disagreement is the whole point: an editor or QC tool that reads the timecode track shows 01:00:00:00 at the first frame, one that reads elapsed time shows zero, and a file where they agree cannot tell you which your tool is doing. Non-drop-frame, since 24 fps has no drop-frame variant.
A file with a known, fixed creation time: the field media libraries sort by, importers use to build folders, and forensic tools read first. Fixed rather than generated at build time, so re-running the generator produces byte-identical output and the published value never goes stale. Two behaviours worth testing against it. MP4 stores the `mvhd` timestamp in seconds since 1904 with no timezone, so anything that displays a local time is applying an assumption; and the stripped file in this group has no creation time at all, which is what a privacy-scrubbed file should look like.
RealMedia container with a short deterministic RealVideo motion pattern for download-only legacy demux and transcode coverage. Stable P8 artifact p8-convert-legacy-rm.
A standards-compliant plain-text email message (.eml) with full headers: the simplest valid RFC 822 message for testing email header parsing and EML import.
A multipart/alternative email carrying both a plain-text and an HTML body, for testing MIME part selection, HTML-part handling and sanitising, and multipart parsing.
A multipart/mixed email with a base64-encoded CSV file attachment, for testing attachment detection, decoding, and extraction from an EML message.
An mbox mailbox concatenating a short three-message email thread with the classic 'From ' separator lines and >From body escaping, for testing mailbox splitting and thread reconstruction.
An HTML newsletter email (multipart/alternative) with a table-based responsive layout and a List-Unsubscribe header, for testing HTML-email rendering, sanitising, and marketing-email parsing.
An order-confirmation / receipt email (multipart/alternative) with an itemised order table in both text and HTML: a transactional-email fixture for testing parsing and data extraction.
A meeting-invitation email carrying an iCalendar (.ics) VEVENT with METHOD=REQUEST, for testing calendar-invite detection, ICS extraction, and RSVP handling.
A bounce / non-delivery report (NDR), a multipart/report message with a human-readable notice, a message/delivery-status part, and the original headers, for testing bounce parsing and delivery-status extraction.
A larger mbox mailbox with a six-message back-and-forth thread, for testing mailbox splitting, thread reconstruction, and pagination over more than a couple of messages.
A multipart/related message with an HTML body referencing a CID-inline PNG, for email client and MIME parser tests.
Nested MIME (mixed wrapping alternative plus a text attachment), for deep MIME tree walkers.
A single-part text/html email with no text/plain alternative: edge case for clients that require multipart/alternative.
A reply carrying In-Reply-To and References headers, for email thread reconstructors.
RFC 822 message with a text/calendar REQUEST attachment, for calendar invite importers.
Cancel twin for the SAMPLE calendar invite: same UID, SEQUENCE bumped, METHOD=CANCEL.
Standalone SAMPLE iCalendar REQUEST for calendar parsers without MIME wrapping.
Standalone SAMPLE iCalendar CANCEL for calendar parsers without MIME wrapping.
S/MIME-shaped SAMPLE with a placeholder PKCS7 part (not a real signature) for MIME structure tests.
Threaded SAMPLE reply at depth 1 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 2 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 3 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 4 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 5 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 6 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 7 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 8 with a long References chain and bulky X-headers.
multipart/report delivery-status SAMPLE with action=failed for DSN parsers.
multipart/report delivery-status SAMPLE with action=delayed for DSN parsers.
multipart/report delivery-status SAMPLE with action=delivered for DSN parsers.
multipart/report delivery-status SAMPLE with action=relayed for DSN parsers.
A quoted-printable text/plain message in utf-8 whose body carries accented French text, guillemets, an em dash and a euro sign. It is the exact twin of the base64 message beside it: both decode to the same 247 octets, so a decoder can be diffed against a known-equal pair.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A quoted-printable text/plain message in utf-8 whose body ends lines with spaces and tabs that quoted-printable must encode as =20 and =09. It is the exact twin of the base64 message beside it: both decode to the same 193 octets, so a decoder can be diffed against a known-equal pair.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A quoted-printable text/plain message in utf-8 whose body holds a single line far past 76 columns, forcing quoted-printable soft breaks. It is the exact twin of the base64 message beside it: both decode to the same 451 octets, so a decoder can be diffed against a known-equal pair.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A quoted-printable text/plain message in iso-8859-1 whose body is single-byte ISO-8859-1 rather than UTF-8, so each umlaut is one octet. It is the exact twin of the base64 message beside it: both decode to the same 176 octets, so a decoder can be diffed against a known-equal pair.
A base64 text/plain message in iso-8859-1 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A quoted-printable text/plain message in utf-8 whose body starts a line with "From " and holds a lone "." line, which quoted-printable escapes as =46rom and =2E. It is the exact twin of the base64 message beside it: both decode to the same 219 octets, so a decoder can be diffed against a known-equal pair.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
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.
Text and HTML alternatives that state different totals and different delivery dates. The spec says the parts must be alternative renderings of the same content, so this fixture shows what a tool extracts when they are not: the answer depends entirely on which part it picks.
The alternative parts are ordered richest-first, the opposite of what RFC 2046 requires. A client that blindly takes the last part shows plain text here and HTML everywhere else, which is exactly the intermittent-looking bug this fixture pins down.
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 same release notes as plain text, Markdown (RFC 7763) and HTML, ordered least-faithful first. Most selectors only know the plain/HTML pair, so this is the fixture that shows whether an unfamiliar middle part is skipped or mistaken for the body.
An HTML body referencing two base64 PNG parts by Content-ID, both resolved. This is the baseline for the three related/cid fixtures beside it: everything a cid resolver needs is present and correctly spelled.
The related container's root is the second part, named by the start= parameter, with an image sitting first. A reader that assumes the first part is always the root displays a PNG as the message body.
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.
Two inline image parts, only one of them referenced by the HTML. Attachment counters disagree loudly on this shape: some report one attachment, some two, some none, and the answer changes what a user sees in the message list.
The canonical rich-mail shape written out in full: a mixed container holding a related container holding an alternative pair, plus a CSV attachment at the outer level. A tree walker has to reach depth three to find the HTML body and still report exactly one attachment.
A forward that embeds the whole original message, headers and all, as a message/rfc822 part, and that original is itself a multipart with its own attachment and threading headers. Extractors routinely stop at the message/rfc822 boundary and miss the nested file.
Two complete messages carried in a multipart/digest, neither part declaring a Content-Type. RFC 2046 makes the default message/rfc822 inside a digest instead of the usual text/plain, so a parser that hardcodes the text default renders raw headers as body text.
The same 16x16 PNG appears twice with the same filename: once inline with a Content-ID, once as a plain attachment. Deduplicating by filename or by content hash collapses the pair and loses one of them, which is how an attachment silently disappears.
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.
Two text/plain parts inside a mixed container, the second marked inline but carrying a filename. Clients split on this: some concatenate it into the body, some list it as an attachment because a filename is present, and the two behaviours look like different messages.
A To: header listing 24 addresses, folded after every comma. Address-list parsers that unfold and split in the wrong order produce addresses with a leading space or lose the display name of every recipient after the first.
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.
An eight-deep References chain folded so each Message-ID sits on its own line. There is no comma between msg-ids in this header, so a parser that splits on the line break rather than unfolding first ends up with ids that carry a leading space.
Two headers folded with horizontal tabs instead of spaces, which RFC 5322 permits exactly as it permits spaces. Parsers that test only for a leading space treat the continuation as a brand-new header and lose the second half of the Subject.
A header line and a body line sitting exactly on the RFC 5322 maximum of 998 octets excluding CRLF. Both are legal, so anything that rejects, wraps, or truncates them is off by one against the spec: this is the reference case for that boundary.
A reply that declares its parent only through In-Reply-To. Threading code that builds ancestry from References alone files this message as a new thread root, splitting a conversation in the message list.
The same reply expressed the other way round: a References chain with no In-Reply-To. Together with its twin it isolates which of the two headers a threading implementation actually reads, since either alone is sufficient under RFC 5322.
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 reply carrying the Exchange threading headers (Thread-Topic and a SAMPLE Thread-Index) next to the standard References chain, plus an X-MS header with an empty value. Empty header values are legal and are a common cause of parser exceptions.
One multipart/report carrying two per-recipient blocks: a permanent 5.1.1 failure and a temporary 4.4.7 delay for the same original message. Bounce processors that read only the first block suppress a good address, or keep retrying a dead one.
A bounce whose third part is the complete original message (headers and body) as message/rfc822. Paired with the headers-only twin beside it, it shows whether a bounce processor can recover the original Message-ID from either shape.
The same bounce as its twin, except the returned content is text/rfc822-headers: the privacy-preserving form most large providers send. A processor keyed on message/rfc822 finds nothing here and reports an un-attributable bounce.
A permanent bounce whose extended status is 5.7.1 (rejected by policy) with Remote-MTA, Original-Recipient and Last-Attempt-Date all present. Suppression lists that key on the 5.x class alone blacklist a perfectly valid address over a sender-side problem.
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.
A set of 24 L2-normalised 16-dimensional text embeddings as JSON: each record pairs an id and its source text with a float vector. A fixture for testing vector stores, similarity search, and embedding loaders. Parquet and .npy twins included.
The same 16-dimensional embeddings as Apache Parquet: id and text columns plus one column per dimension. The columnar twin, for testing analytics engines and Parquet-based vector pipelines.
The embeddings as a raw NumPy array: a 24×16 float32 matrix in .npy format, loadable with numpy.load. The binary twin of the JSON and Parquet files, for testing tensor and matrix loaders.
A simple rendered street scene with a person, a car, and a tree at known pixel coordinates: the image the COCO, YOLO, and Pascal-VOC annotation twins describe. A fixture for testing object-detection loaders and annotation converters.
Object-detection annotations for the scene in the COCO JSON format: images, categories, and per-object bounding boxes as [x, y, width, height]. Grouped with YOLO and Pascal-VOC twins for testing annotation-format conversion.
The same detection boxes in the YOLO text format: one object per line as class id and box centre, width, and height normalised to 0–1. The format twin of the COCO and VOC annotations.
The same detection boxes in the Pascal VOC XML format: a per-image annotation with size, and one object element per box with pixel corner coordinates. The XML twin of the COCO and YOLO annotations.
A 3-class confusion matrix as CSV: rows are the true class, columns the predicted class, cells the counts. Paired with a JSON twin for testing metric parsers and evaluation visualisers.
The same 3-class confusion matrix as JSON: a labels array plus a nested counts matrix. The structured twin of the CSV, for testing evaluation tooling.
A genuinely-valid safetensors file with two small float32 tensors (36 parameters total): an 8×4 weight and a length-4 bias. The values are meaningless sample data, not a trained model; a fixture for testing safetensors loaders and weight inspectors.
Pascal VOC XML annotations for the warehouse detection scene.
A one-node identity graph with a fixed 1x4 float tensor, useful as the smallest loader and inference smoke test. The matching JSON input and expected output make the model immediately usable in a CI inference assertion.
A two-node affine transform with fixed weights and bias, exercising initializers, MatMul dimensions and Add broadcasting. The matching JSON input and expected output make the model immediately usable in a CI inference assertion.
A two-input Add graph where a length-two bias broadcasts across a 2x2 matrix, checking input binding and broadcasting rules. The matching JSON input and expected output make the model immediately usable in a CI inference assertion.
A ReduceSum graph with a symbolic batch dimension and fixed feature width, for dynamic-shape import and batch-output tests. The matching JSON input and expected output make the model immediately usable in a CI inference assertion.
Tiny multi-language SAMPLE monorepo ZIP (web/api/util/scripts) for unpack-then-lint and monorepo tooling.
A multi-resolution favicon.ico bundling 16, 32, 48, and 64 px images of the brand mark, for testing favicon parsers, ICO decoders, and multi-image icon handling.
A scalable SVG favicon of the brand mark: the modern crisp-at-any-size icon format, for testing SVG favicon support and vector-to-raster favicon pipelines.
An SVG sprite sheet defining five reusable icons as <symbol> elements referenced by <use href='#id'>, for testing SVG sprite pipelines and icon systems. Paired with a PNG sprite twin.
A 320×64 PNG icon sprite (five 64×64 cells): the raster twin of the SVG sprite, for testing background-position sprite techniques and sprite slicers.
Four articles of a fictional publication as RSS 2.0, with a self-referential atom:link, non-permalink tag: GUIDs, RFC 822 dates and full HTML bodies in content:encoded. One of three twins carrying identical content, so a feed converter can be diffed against a known answer.
The same four articles as Atom 1.0: tag: ids identical to the RSS twin, RFC 3339 published and updated timestamps, escaped HTML content, and both alternate and self links. For diffing an RSS-to-Atom converter against a known answer.
The third twin: the same four articles as JSON Feed 1.1, using the 1.1 `authors` array rather than the 1.0 singular form, with ids, URLs, summaries, HTML bodies and timestamps identical to the RSS and Atom files. The reference output for an XML-to-JSON feed converter.
Binary DER encoding of the SAMPLE root CA certificate: the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.
Binary DER encoding of the SAMPLE intermediate CA certificate: the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.
Binary DER encoding of the SAMPLE leaf certificate: the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.
Binary DER twin of the SAMPLE CRL: the exact encoding a CRL distribution point serves over HTTP. Use it to test binary CRL fetching and caching paths that never see PEM armour.
A degenerate (certificates-only) PKCS#7 structure holding all three SAMPLE certificates under BEGIN PKCS7 armour: the payload Windows and Java tools distribute as a .p7b. It carries no private key and no signature over any content.
Binary DER form of the same three-certificate PKCS#7 bundle, the encoding a .p7b download actually uses. Use it to test importers that never see the PEM armour.
The identical key material wrapped in the legacy PKCS#1 container (BEGIN RSA PRIVATE KEY), which omits the algorithm OID that PKCS#8 carries. Diff it against its PKCS#8 twin to see exactly what a container migration changes.
The same P-256 scalar in the SEC 1 container (BEGIN EC PRIVATE KEY), which names the curve inline instead of through a PKCS#8 algorithm identifier. Some deployment tools accept only one of the two.
The same modulus and exponent in the raw PKCS#1 RSAPublicKey container, without the algorithm-identifier wrapper. Libraries routinely accept one armour and reject the other, so the pair is the test.
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.
240 cases across six classes, three of them failing. Big enough to time a parser and to check that a report UI paginates or virtualises rather than rendering every row, but still small enough to read.
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.
Every optional run-metadata attribute a JUnit suite may carry (timestamp, hostname, package, id) plus a properties block holding build and branch identifiers. Use it to test that a dashboard reads build context from the report instead of from its own environment.
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.
A <properties> block holding an empty value, an escaped ampersand in a branch name and a JVM options string with spaces. Use it to check that build metadata survives extraction with its entities unescaped exactly once.
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.
Test names in German, French, Japanese, Greek and Russian, stored as UTF-8 with no BOM and an explicit encoding declaration. A reporter that assumes the platform default encoding produces mojibake here rather than an error.
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.
Cases annotated with the source file and line they were declared on, as pytest and several JS runners emit. This is what a code-review annotation bot needs to place a failure comment on the right line of the right file.
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.
The aggregate answer key for the 40-build history in this group: runs, passes, failures and failure rate per test, with each test labelled stable or flaky. Use it to score a detector rather than eyeballing 240 JSONL records.
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 reference LCOV tracefile: one record per source file with FN/FNDA function records, real BRDA branch records (block, branch and taken count, with '-' for a branch never reached) and DA line hits, closed by the LF/LH, FNF/FNH and BRF/BRH counters. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The Cobertura serialisation of the same run, with packages, classes, per-method line rates and condition-coverage attributes on every branching line. Cobertura expresses coverage as rates rather than counts, so this is the file that catches converters rounding a percentage into a hit count. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The JaCoCo serialisation, which reports missed/covered pairs rather than found/hit and adds INSTRUCTION and COMPLEXITY counters no other format carries. Converters routinely swap missed for covered here, which inverts the whole report. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The Clover serialisation, whose <metrics> element rolls statements, conditionals and methods into a single elements/coveredelements pair. Anything reading only that pair reports a blended percentage that matches none of the other three formats unless the components are separated first. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The raw Istanbul document nyc and Jest write before any reporter runs: statementMap, fnMap and branchMap giving source locations, with the s, f and b objects holding the hit counts. Branch counts here are arrays per branch point, which is why converting to LCOV doubles the branch total if the array is not flattened. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The compact json-summary reporter output: a total block plus one block per file, each with lines, statements, functions and branches as total/covered/skipped/pct. This is what coverage badges and pull-request comments are generated from. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The same coverage as a flat table with a TOTAL row, for spreadsheets, trend charts and diffing two runs without an XML parser. The TOTAL row is the arithmetic sum of the four file rows, so it doubles as a checksum on any tool that regenerates it. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The Markdown comment a coverage bot posts on a pull request: a headline percentage, a per-file table and the uncovered line numbers. Useful for testing Markdown table rendering and for checking that a bot's generated comment matches the machine-readable report it claims to summarise. Every file in this group describes the same four-file source tree and reports 127/140 lines, 17/24 branch outcomes and 18/20 functions, so a converter can be diffed against a known answer.
The same tracefile with every BRDA, BRF and BRH line removed: what a runner emits when branch instrumentation is off. A gate that reads branch coverage from this file must report it as unavailable, not as 0%, or an unconfigured project looks like a badly tested one.
Records containing FN/FNDA/FNF/FNH and nothing else: no DA lines, no LF or LH. Merge tools that assume every record ends with LF/LH either crash here or invent a zero line count for a file that simply was not line-instrumented.
Two TN: blocks (a unit run and an integration run), each carrying a full record for the same two source files. A correct merge sums the DA hit counts per line and recomputes LH; a tool that keeps the last record seen throws away the unit run entirely.
Every instrumented line present with a hit count of zero: the shape of a report from a run in which the tests never loaded the instrumented code. It is not an empty file, and conflating the two hides a broken test harness behind a missing-report warning.
Every line hit at least once, so LH equals LF exactly. The upper-bound control for a coverage gate, and the case that catches percentage formatting that renders 100% as 100.0% or, worse, rounds 99.95% up to it.
Three named test runs in one tracefile, each covering a different part of the tree, reported via the TN: record most tools quietly discard. Keeping the name is what lets a report answer which suite covered a given line.
Cobertura with a condition-coverage attribute on every branching line, written in the "50% (1/2)" form. The percentage and the fraction can disagree in real reports, so a parser should read the fraction and treat the percentage as derived.
The same coverage split into one package per source directory with dotted names, the layout a JVM project produces. Reports that key on class name alone collide as soon as two packages hold a class of the same name, which this file is shaped to expose.
A structurally complete Cobertura report in which line-rate and branch-rate are 0.0 everywhere. The counterpart to the zero-coverage LCOV file, for checking that a converter keeps the class and method structure when there is nothing covered to describe.
Three <source> roots with class filenames given relative to them, which is how Cobertura represents a multi-root project. A viewer must try each root in turn to resolve a file; one that assumes a single root shows "source not found" for most of the report.
All six JaCoCo counter types present at every level of the document: method, class, sourcefile, package and report. Tools usually read only the report-level LINE counter; this file is for checking that per-method and per-package rollups agree with it.
A report merged from three separate JVM sessions, each recorded as its own <sessioninfo> with start and dump timestamps. The counters are already the merged totals, so summing per-session anything from this file is a mistake it exists to catch.
The aggregate form a multi-module build produces: packages nested inside a <group> rather than directly under <report>. Parsers with a hardcoded report/package path find nothing here and report a module with no coverage at all.
Per-method INSTRUCTION, LINE, COMPLEXITY and METHOD counters for all 20 methods, 2 of which were never entered. This is the detail a "which functions are untested" report needs and the level at which most converters stop.
A tracefile sitting meets the gate exactly against the 80% minimum in this group's gate config: 112 of 140 lines, 80.00%. 80.00% is exactly the configured minimum, so a > comparison fails the build and a >= comparison passes it: the single most common off-by-one in a coverage gate.
A tracefile sitting misses the gate by one line against the 80% minimum in this group's gate config: 111 of 140 lines, 79.29%. 79.29% is one covered line short of the gate, the smallest possible failure.
A tracefile sitting clears the gate by one line against the 80% minimum in this group's gate config: 113 of 140 lines, 80.71%. 80.71% clears the gate by one covered line, the smallest possible pass.
The source feature for this whole group: a Background with a data table, a plain scenario, a Scenario Outline expanded by two Examples tables, and a scenario asserting against a doc string. It compiles to exactly six pickles and 32 pickle steps: the numbers the cucumber-messages and cucumber.json twins next to it report.
The machine twin of checkout.feature: the cucumber-messages envelope stream a runner emits, with meta, source, gherkinDocument, one pickle per expanded scenario, and paired testStepStarted/testStepFinished envelopes carrying nanosecond durations. Written as NDJSON because that is the format's actual wire shape: one envelope per line, not a JSON array.
The legacy cucumber.json report for the same run: the format nearly every BDD dashboard still ingests. Durations are in nanoseconds here and in a nested {seconds, nanos} object in the messages twin, which is the single most common unit bug when converting between the two.
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.
A named Background whose two steps are prepended to all three scenarios, plus feature-level tags that every scenario inherits and scenario-level tags that only some carry. Tag filtering is where this file earns its keep: @slow selects one scenario by its own tag and all three by inheritance from the feature.
One outline expanded by two separate Examples tables, the second of which carries its own @edge tag. Expansion must produce five scenarios, and only the two from the tagged table may match a run filtered on @edge: a distinction parsers that flatten the tables lose.
A step argument table with a header row, followed by two doc strings: one plain and one carrying a json content type after the opening delimiter. Doc string indentation is relative to the delimiter, so the receipt body must keep its internal column alignment while losing the six leading spaces.
Two Rule blocks, the first with its own Background that applies only to the examples inside it. Parsers written before Gherkin 6 either reject Rule outright or, worse, hoist the Background to the whole feature and add a step to the third example that was never there.
Steps exercising every argument shape a step-definition matcher has to handle: quoted strings with escaped inner quotes, integers, decimals, a comma-and-and list, the But keyword, and angle brackets in a plain Scenario where they are literal text rather than outline placeholders.
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.
A complete Robot Framework suite with all four common sections, scalar, list and dictionary variables, a continued line using ..., and user keywords with arguments. Robot separates arguments on two or more spaces, so a parser splitting on a single space merges every keyword call into one token.
The template form, in which the *** Test Cases *** header itself names the argument columns and each row becomes one test. Five tests share a single keyword body, and a parser that reads the header row as a test name reports six.
A resource file: keywords, variables and imports with no *** Test Cases *** section at all, meant to be imported by the suites next to it. Tooling that requires at least one test case rejects a perfectly ordinary resource, and keyword defaults such as ${qty}=1 are where argument parsers usually stop.
A load-test run summary in the shape a threshold-checking CI step consumes: totals, per-scenario percentiles, and three named thresholds each carrying its limit, the observed value and a pass flag. Publishing the limit next to the observation is what lets a gate be re-evaluated without rerunning the test.
The percentile table a performance report renders as a chart, with mean, p50, p95, p99 and max for each of the four scenarios. The same numbers appear inside the JSON summary in this group, so a chart built from either source can be diffed against the other.
A complete release test plan for the fictional Novus Checkout Service: scope, test levels, entry and exit criteria, a risk table and deliverables. Useful as a Markdown-rendering fixture with three tables and nested lists, and as a realistic input for documentation tooling that has to extract structure from prose.
Twelve test cases with level, priority, the requirement each covers, preconditions, steps and expected result: the table a test-management import expects. Eleven of the twelve are automated, and the requirement column joins this file to the traceability matrix next to it.
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.
A real binary file carried inside a text patch: zlib-deflated, encoded in git's own base85 alphabet, split into length-prefixed lines, and followed by the reverse `literal 0` payload that makes the patch revertible. The index line uses full 40-character hashes because `--binary` implies `--full-index`, and the recorded blob sha1 is the genuine object id of the attached PNG.
The same 13-span trace serialised the way a stock proto3 JSON marshaller writes it: trace and span IDs base64-encoded and span kind and status as enum names rather than numbers. Paired with the hex/numeric OTLP/JSON twin so a receiver can be tested against both encodings of one payload.
The checkout trace in the Jaeger query-API shape: a data array holding one trace, spans carrying microsecond startTime and duration, CHILD_OF references, typed tags and a per-service processes map. The same span tree as the OTLP and Zipkin twins, so a converter can be scored exactly.
The checkout trace as a flat Zipkin v2 span list with localEndpoint, string-only tags and annotations. Two conversions are deliberately visible: Zipkin has no INTERNAL kind, so those two spans omit kind, and every typed attribute is stringified.
The same 13 spans flattened to a CSV table: span and parent IDs, service, name, kind, start timestamp, duration and status. The shape a trace store exports for spreadsheet analysis, and a readable ground truth to diff the three JSON twins against.
One HTTP server span using the old OpenTelemetry attribute names (http.method, http.url, http.status_code, net.peer.ip), and the old low-cardinality span name. Paired with its modern twin so a migration shim can be tested against a known before-and-after.
The same HTTP server span written with the stable attribute names (http.request.method, url.path, http.response.status_code, client.address), and the route-templated span name the stable conventions require. The target state for a migration shim.
The OTLP summary type: quantiles computed on the client, kept only for translating legacy Prometheus summaries. It carries the same four quantiles as the Prometheus summary fixture, and like that one it cannot be re-aggregated across instances without producing a wrong number.
Cumulative sums whose start timestamp stays fixed across exports, so every point is the running total since process start. Paired with a delta-temporality twin covering the same window, because converting between the two is a stateful operation that a bridge must get right in both directions.
The same 24 hours of cart updates as six delta points, each with its own start and end timestamp covering a four-hour window. The delta twin of the cumulative fixture: summing these must reproduce the cumulative total exactly, and a gap or overlap in the windows is the failure to catch.
An allocation profile in the same folded syntax as the CPU profiles, but weighted in bytes rather than samples. The format carries no unit, so a viewer that assumes samples renders 65 MB of allocation as 68 million samples, which is what this fixture is for.
A heap profile measuring bytes still live at the sample point, not bytes ever allocated, which is why its shape differs from the allocation profile of the same process. 620 MB retained across five sites, with an unbounded session cache at the top.
A complete CycloneDX 1.6 SBOM in JSON for a fictional application and its nine dependencies, with purls, SHA-256 hashes, supplier records, external references and an explicit dependency graph. Every package, version, hash and licence is fictional: the tree describes nothing real.
The same fictional CycloneDX 1.6 SBOM serialised as XML against the cyclonedx.org/schema/bom/1.6 namespace: the JSON twin of this file carries identical components and edges, so a converter can be diffed exactly. Every package, version, hash and licence is fictional: the tree describes nothing real.
A CycloneDX 1.5 SBOM of the same fictional tree, useful for spec-version migration tests: 1.5 introduced the object form of metadata.tools and this file uses it, while dropping the 1.6-only external references. Every package, version, hash and licence is fictional: the tree describes nothing real.
A CycloneDX 1.4 XML SBOM of the same fictional tree: the version most long-lived tooling emitted first, kept for backwards-compatibility tests against the 1.5 and 1.6 documents in this family. Every package, version, hash and licence is fictional: the tree describes nothing real.
A CycloneDX 1.6 SBOM whose dependencies array contains two diamonds: the fictional example-logger is reached through three parents and example-json-path through two, both resolving to a single node. Every package, version, hash and licence is fictional: the tree describes nothing real.
A CycloneDX 1.6 SBOM that carries its own vulnerabilities array: four clearly-marked SAMPLE advisories in the invented NOVUS-SAMPLE namespace, with CVSS v3.1 vectors, CWE classes and affected version ranges. Every package, version, hash and licence is fictional: the tree describes nothing real.
A CycloneDX SBOM whose root component is an OCI container image rather than an application, mixing a fictional operating-system package with language packages: the shape an image scanner emits. Every package, version, hash and licence is fictional: the tree describes nothing real.
A CycloneDX SBOM that uses compound SPDX licence expressions (AND, OR, WITH and a LicenseRef), instead of plain licence ids, for testing compliance scanners that must evaluate the expression grammar. Every package, version, hash and licence is fictional: the tree describes nothing real.
Every fictional component in this CycloneDX SBOM carries three hash algorithms and five external-reference types (distribution, vcs, issue-tracker, documentation, build-system). Every package, version, hash and licence is fictional: the tree describes nothing real.
An SPDX 2.3 SBOM in JSON describing the same fictional tree as the CycloneDX documents in this category, with SPDXIDs, purl external references, SHA-256 checksums and DESCRIBES/DEPENDS_ON relationships. Every package, version, hash and licence is fictional: the tree describes nothing real.
The same SPDX 2.3 SBOM in the specification's plain-text tag-value form: the serialisation many licence-compliance tools still read first, and the exact twin of the JSON document in this family. Every package, version, hash and licence is fictional: the tree describes nothing real.
An SPDX 2.3 tag-value SBOM that descends to file level: two fictional build outputs with SHA-1 and SHA-256 checksums, per-file licence findings, and CONTAINS relationships back to their package. Every package, version, hash and licence is fictional: the tree describes nothing real.
An SPDX tag-value SBOM emphasising its relationship block: one DESCRIBES edge and ten DEPENDS_ON edges that form the same two diamonds as the CycloneDX graph fixture. Every package, version, hash and licence is fictional: the tree describes nothing real.
An SPDX tag-value SBOM that declares a non-standard LicenseRef with its extracted text and uses it inside compound expressions: the case that breaks compliance tools which assume every licence is an SPDX id. Every package, version, hash and licence is fictional: the tree describes nothing real.
The same fictional tree as an SPDX 2.2 tag-value document (the version still produced by older toolchains) for upgrade and compatibility tests against the 2.3 twin in this family. Every package, version, hash and licence is fictional: the tree describes nothing real.
An SPDX 3.0 SBOM in JSON-LD (the element-graph model that replaced the 2.x document layout) describing the same fictional tree with software_Package elements and typed Relationship nodes. Every package, version, hash and licence is fictional: the tree describes nothing real.
An SPDX tag-value SBOM whose document name is a fictional container image digest rather than an application version: the naming convention image scanners use, and the SPDX counterpart of the CycloneDX container fixture. Every package, version, hash and licence is fictional: the tree describes nothing real.
The field-by-field map between the CycloneDX 1.6 and SPDX 2.3 documents in this category, plus the five invariants a correct conversion preserves and the three things it legitimately loses. Every package, version, hash and licence is fictional: the tree describes nothing real.
The same fictional component tree flattened to a spreadsheet-friendly CSV (name, version, licence, depth, purl and a SHA-256 prefix) for testing the export path SBOM tools offer alongside JSON. Every package, version, hash and licence is fictional: the tree describes nothing real.
The SPDX 2.3 SBOM in its YAML serialisation: the third form the specification defines alongside JSON and tag-value, and the one most often hand-edited in a repository. Every package, version, hash and licence is fictional: the tree describes nothing real.
An npm lockfile in the modern v3 layout: a flat packages map keyed by node_modules path, with resolved tarball URLs and sha512 subresource integrity for nine fictional dependencies. 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.
The original npm v1 lockfile layout (a nested dependencies object with requires maps and no packages section) still found in long-lived repositories and needed by any migration path. Every package, version, hash and licence is fictional: the tree describes nothing real.
The shrinkwrap variant of an npm lockfile: identical in structure to package-lock.json but published inside the package tarball, so tooling that keys on the filename must handle both. Every package, version, hash and licence is fictional: the tree describes nothing real.
A Yarn 1 lockfile in its own line-oriented grammar (quoted descriptor headers, two-space indented fields, resolved URLs with a SHA-1 fragment), which looks like YAML but is not. 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.
A pnpm v9 lockfile with its three-section layout (importers for declared specifiers, packages for resolution metadata and snapshots for the resolved edges) pinning the same fictional tree. Every package, version, hash and licence is fictional: the tree describes nothing real.
Bun's text lockfile, where each package is a positional array of descriptor, dependency map and integrity string rather than an object: a shape that breaks parsers assuming every lock entry is keyed. Every package, version, hash and licence is fictional: the tree describes nothing real.
A hash-pinned pip requirements file with two sha256 hashes per fictional package (wheel and sdist) and line continuations: the form `--require-hashes` installs demand. Every package, version, hash and licence is fictional: the tree describes nothing real.
A pip constraints file pinning the same nine fictional packages. Constraints bound a resolution without adding dependencies, so a tool that treats this like requirements.txt installs nine packages too many. Every package, version, hash and licence is fictional: the tree describes nothing real.
A pip-compile output where every pin carries a `# via` annotation naming the requirement that pulled it in: the only place the transitive graph survives in a pip workflow. Every package, version, hash and licence is fictional: the tree describes nothing real.
A Pipenv lockfile in JSON, with the _meta hash that ties it to its Pipfile, a named index source and nine fictional pinned packages in the default section. Every package, version, hash and licence is fictional: the tree describes nothing real.
A Poetry lockfile: TOML array-of-tables entries with per-artifact sha256 hashes, a [package.dependencies] table per package and the content-hash that binds the lock to pyproject.toml. Every package, version, hash and licence is fictional: the tree describes nothing real.
A uv lockfile in TOML, recording an sdist and a wheel per fictional package with inline tables carrying url, hash and byte size: a newer layout than poetry.lock and a useful contrast for parser tests. Every package, version, hash and licence is fictional: the tree describes nothing real.
A conda explicit lock: an @EXPLICIT marker followed by one fully-resolved URL per fictional package with an md5 fragment, no solver involved, which is exactly what makes it a lockfile. Every package, version, hash and licence is fictional: the tree describes nothing real.
A Rust Cargo.lock in the version 4 format: TOML [[package]] tables with a registry source, a sha256-shaped checksum and a name-only dependencies array that resolves against the other tables. Every package, version, hash and licence is fictional: the tree describes nothing real.
The same fictional Rust tree pinned by a version 3 Cargo.lock, for testing that a reader keys on the declared version rather than assuming the newest format. Every package, version, hash and licence is fictional: the tree describes nothing real.
A Go module manifest with separate direct and // indirect require blocks for the fictional tree. Served with a .txt extension because go.mod has no registered media type; the content is verbatim go.mod syntax. 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 PHP composer.lock in JSON, pinning each fictional package by both a git reference and a dist zip shasum, with a content-hash binding it to composer.json. 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.
A CocoaPods lockfile: a YAML-subset document listing pods with their nested requirements, a SPEC CHECKSUMS block of SHA-1 values and the CocoaPods version that produced it. 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 Dart pubspec.lock in YAML, labelling each fictional package as direct main or transitive and recording a sha256 in its description block along with the SDK constraint. Every package, version, hash and licence is fictional: the tree describes nothing real.
A NuGet lockfile keyed by target framework, distinguishing Direct from Transitive entries and recording a base64 contentHash for each fictional package. Every package, version, hash and licence is fictional: the tree describes nothing real.
A Gradle dependency lockfile: one `group:artifact:version=configurations` line per fictional module plus the `empty=` line that records configurations resolving to nothing. Every package, version, hash and licence is fictional: the tree describes nothing real.
Declared range against resolved version for every fictional package pinned by the lockfiles in this category: the table a review needs to see which pins drifted from their manifest ranges. Every package, version, hash and licence is fictional: the tree describes nothing real.
A Trivy-shaped filesystem scan report with four SAMPLE findings against a fictional npm lockfile, one per severity band, each with a CVSS v3.1 vector, CWE class and fixed version. 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 same four SAMPLE findings expressed as SARIF 2.1.0 (the format code-scanning dashboards ingest) with a rules array, security-severity properties and physical locations. 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 Grype-shaped report of the same four SAMPLE advisories, with the match detail block that explains WHY each package matched: the field that makes false positives diagnosable. 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.
A single OSV-schema advisory record for a fictional package, with a SEMVER range expressed as introduced/fixed events rather than as a version string: the part naive parsers get wrong. 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.
All four SAMPLE advisories as newline-delimited OSV records: the bulk shape an advisory database is loaded from, where each line must parse independently. 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 OSV-Scanner report that nests full OSV records under each affected package and adds the groups array that collapses aliases into one finding: the structure de-duplication depends on. 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 npm audit v2 report keyed by package name, with the via chain, the effects list showing which fictional parents are impacted, and npm's own severity vocabulary where MEDIUM is spelled 'moderate'. 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.
A cargo-audit report that shows three findings while a fourth is on the ignore list, plus an unmaintained-crate warning, so a gate must decide whether warnings count against it. 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 Dependency-Check-shaped JSON report, including the evidence-collection block that records how a package was identified and the confidence attached to that identification. 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.
A CycloneDX VEX document asserting a different analysis state for each of the four SAMPLE advisories, so a suppression pipeline can be tested against every branch at once. 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 OpenVEX document covering all four status values, with the justification and impact statement OpenVEX requires alongside not_affected and the action statement it requires alongside affected. 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 CSAF 2.0 VEX advisory with the nested product tree that CSAF requires (vendor, product name, product version), and product_status buckets rather than a per-statement status field. 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 four SAMPLE advisories flattened to one row each: the export a security review circulates, and the reference answer for any converter run against the Trivy, Grype or OSV reports here. 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 human-readable end of the pipeline: a triage report that records a decision and a reachability path for each of the four SAMPLE findings, matching the states asserted by the VEX documents here. 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 unsigned in-toto Statement carrying a SLSA v1 provenance predicate for a fictional release: build definition, external parameters, resolved dependencies with digests, and run details naming an invented builder. Every package, version, hash and licence is fictional: the tree describes nothing real.
The predecessor predicate: SLSA v0.2 uses invocation/materials/buildConfig where v1 uses buildDefinition/runDetails, so this file is the migration test for any verifier that must accept both. Every package, version, hash and licence is fictional: the tree describes nothing real.
A VSA (the attestation a verifier issues so downstream consumers do not have to re-verify the whole chain) recording a PASSED result against a fictional SLSA L3 policy and the level distribution of dependencies. Every package, version, hash and licence is fictional: the tree describes nothing real.
An in-toto link file recording one build step: the materials that went in, the products that came out and their sha256 digests, wrapped in the signed/signatures envelope in-toto uses. 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.
An attestation that binds an SBOM to an artifact digest rather than shipping the SBOM loose: the pattern keyless signing produces, complete with the empty keyid that identity-based signing leaves behind. 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.
An in-toto statement whose predicate is an entire SPDX 2.3 document: the nesting that makes attestation payloads large and that a size-limited verifier has to cope with. Every package, version, hash and licence is fictional: the tree describes nothing 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.
The five checks a verifier must perform against the attestation fixtures in this category, and the exact result each one should produce, including the two that are meant to fail. Every package, version, hash and licence is fictional: the tree describes nothing real.
An explicit node/edge dependency graph with in-degree, out-degree and depth precomputed, plus a diamonds array naming the two shared nodes and their parents: the reference answer for any graph builder run against the SBOMs and lockfiles here. Every package, version, hash and licence is fictional: the tree describes nothing real.
The same diamond graph as Graphviz DOT, with edge labels carrying the declared semver range and the two diamond joins filled, renderable to SVG and diffable against the JSON twin. 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 dependency graph as Mermaid, for embedding in Markdown documentation, labelled edges carry the declared range and a classDef highlights the two diamond joins. Every package, version, hash and licence is fictional: the tree describes nothing real.
The dependency graph in GraphML, with typed attribute keys for node version, licence and depth and for edge range: the interchange format graph databases and analysis tools import. Every package, version, hash and licence is fictional: the tree describes nothing real.
The nested tree `npm ls --json` prints, where a shared dependency is REPEATED under every parent rather than deduplicated, so counting objects gives a larger number than the graph has nodes. Every package, version, hash and licence is fictional: the tree describes nothing real.
The console tree with box-drawing characters and `deduped` markers on repeat visits: the output people paste into issues, and a genuine test of whether a scraper handles non-ASCII tree glyphs. Every package, version, hash and licence is fictional: the tree describes nothing real.
Maven's dependency tree, complete with the [INFO] log prefix that has to be stripped before the tree can be read and the five-part coordinate form Maven uses. Every package, version, hash and licence is fictional: the tree describes nothing real.
Gradle's dependency report, which marks repeat subtrees with `(*)` and explains the marker in a footer, so a parser has to resolve those references back to their first occurrence. Every package, version, hash and licence is fictional: the tree describes nothing real.
`go mod graph` output: a flat edge list, one `parent@version child@version` pair per line with no indentation at all, the simplest graph serialisation in this category and the easiest to diff. Every package, version, hash and licence is fictional: the tree describes nothing real.
Cargo's tree output, which writes versions with a leading `v` and marks already-shown subtrees with `(*)`: close enough to npm's tree to fool a parser, different enough to break one. Every package, version, hash and licence is fictional: the tree describes nothing real.
pipdeptree output, whose top level is an ARRAY rather than an object (the shape that breaks a loader written against npm's tree) with both installed and required versions on every edge. Every package, version, hash and licence is fictional: the tree describes nothing real.
The written explanation of both diamonds in this category (the one that resolves to a single shared node and the peer conflict that forces a nested duplicate) with the four assertions a resolver test should make. Every package, version, hash and licence is fictional: the tree describes nothing real.
The master dataset for this category: five towns, three roads, three parcels (one with a courtyard hole), a lake with an island, a buoy MultiPoint and the county boundary, as an RFC 7946 FeatureCollection. Kestrel Bay County is invented: open ocean at 47 N / 12.5 W, matching no real place, settlement, road or parcel.
The same 14 features with every optional byte of whitespace removed. Pair it with the pretty-printed master to test that a parser's output is whitespace-independent and that a formatter round-trips without reordering members.
The five towns as a plain CSV with separate longitude and latitude columns: the most common way point data actually arrives. Convert it to GeoJSON and diff against the Point features in the master to score column-order and axis-order handling.
Every geometry in the territory as a bare WKT string, one per line and in master order. Attributes are deliberately absent so the file isolates geometry serialisation from attribute mapping.
Attributes plus a quoted WKT geometry column: the shape PostGIS `COPY`, DuckDB spatial and QGIS delimited-text imports expect. The geometry field contains commas, so it exercises quoted-field parsing as well as geometry decoding.
The same 14 features as KML Placemarks, with the multi-point buoys expressed as a MultiGeometry and the two holed polygons using innerBoundaryIs. KML orders coordinates longitude-first like GeoJSON, which makes it the least surprising twin in this group.
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.
The towns and roads in OSM XML: tagged nodes, three highway ways sharing the junction node at Kestrel Bay, and a route relation over them. All object IDs are negative (the convention for objects that have never been uploaded), so nothing here can be mistaken for real OSM data.
The territory as TopoJSON with no quantization and no transform, so arc coordinates are the raw WGS 84 positions. Decoding it must reproduce the master GeoJSON exactly. Which makes it the reference case before the quantized fixtures introduce rounding.
A one-feature FeatureCollection holding a single position, so a reader can be exercised on Point in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.
A one-feature FeatureCollection holding three harbour buoys, so a reader can be exercised on MultiPoint in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.
A one-feature FeatureCollection holding the four-vertex Coast Road, so a reader can be exercised on LineString in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.
A one-feature FeatureCollection holding all three roads as one geometry, so a reader can be exercised on MultiLineString in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.
A one-feature FeatureCollection holding a simple four-corner parcel, so a reader can be exercised on Polygon in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.
A one-feature FeatureCollection holding a parcel with a courtyard cut out of it, so a reader can be exercised on Polygon in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.
A one-feature FeatureCollection holding the three parcels as one geometry, so a reader can be exercised on MultiPolygon in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.
All seven RFC 7946 geometry types in a single FeatureCollection. Formats with a single-geometry-type-per-layer model (shapefile, most database tables) cannot hold this in one layer, so it is the fixture that reveals how a converter splits or refuses it.
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: 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.
Four positions with a third element, which RFC 7946 defines as height in metres above the WGS 84 ellipsoid. Two-dimensional pipelines commonly truncate the third element without saying so, and this file is what proves whether yours does.
The full territory quantized onto a 10,000-step grid with a transform block and delta-encoded arc positions: the default TopoJSON encoding. Rounding is bounded by the grid spacing, which over this 0.28-degree extent is about 2.2 m.
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.
Two adjacent parcels that share their common boundary as a single arc: West Field references it as 0 and East Field as ~0, the negative-index form that means traverse it backwards. Storing the boundary once is the whole point of TopoJSON, and it is also where naive decoders produce gaps or slivers.
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.
One topology carrying three separately named objects (towns, roads and areas) that all index into the same arc pool. This is how a single TopoJSON file ships what would otherwise be three layers, and readers that assume exactly one object silently show only the first.
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.
Exactly what the shared-arc topology decodes to: two polygons whose rings are stitched from arcs 0, 1 and 2 with arc 0 reversed for the eastern parcel. Because that file is unquantized, this comparison is exact rather than tolerance-based.
The baseline GPS trace for this category: 24 timestamped, elevated trackpoints in a single segment, walking the Coast Road of the invented territory. Every other GPX fixture here is this file with one thing changed.
A `rte` element: an ordered list of waypoints describing a planned route, with no timestamps because it has not been travelled yet. Many importers only look for `trk` and report this perfectly valid file as empty.
Five `wpt` elements for the towns of the territory, with names, symbols and descriptions but no track or route. It is the GPX equivalent of a point layer, and the third of the three top-level GPX content types.
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.
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.
Five town Placemarks with plain-text descriptions and no styling: the smallest useful KML and the baseline for the rest of this subcategory. Coordinates match the master territory, so a KML-to-GeoJSON conversion can be diffed against a known answer.
The three roads as LineString Placemarks with `tessellate` set, which tells a globe renderer to drape the line over terrain rather than drawing it as a straight chord. Converters that drop the flag produce lines that tunnel through hills.
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.
Shared `Style` blocks referenced by `styleUrl`, plus a `StyleMap` pairing normal and highlight states. KML colours are written aabbggrr rather than the usual rrggbbaa, which is why converted maps so often come out with red and blue swapped.
Eight Placemarks arranged in three levels of Folder, the hierarchy KML uses for layer trees. GeoJSON has nothing equivalent, so a converter must either flatten and record the path or lose the structure entirely, and this file makes which one it did obvious.
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.
Four extruded points whose third coordinate means three different things depending on the `altitudeMode` beside it: ignored when clamped, height above terrain when relative, height above the ellipsoid when absolute. Copying the number without the mode changes what the data says.
Attributes carried in `ExtendedData/Data` elements, which have names and display names but no declared types: every value is a string. Importers must infer that population is a number, and this is where a silently wrong inference starts.
A `gx:Track` from the Google KML extension: ten `when` timestamps followed by ten `gx:coord` positions, paired by index rather than nested. Note the coordinates are space-separated here even though core KML uses commas: a detail that breaks parsers reusing the same splitting code.
The minimal KMZ: a ZIP holding exactly one `doc.kml` at the archive root and nothing else. Readers are supposed to open the first .kml they find, and most look for the conventional name: this file satisfies both rules.
A KMZ whose style points at `files/markers/town.png` inside the same archive. Resolving that relative href against the archive rather than the filesystem is the whole job of a KMZ reader, and it is where extract-then-parse implementations break.
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.
The geometry half of a point shapefile: a 100-byte header carrying the shape type and bounding box, then five 20-byte Point records. The file is useless on its own: attributes live in the .dbf and the coordinate system in the .prj, which is the point of shipping the whole component set.
The one-line WKT that tells a reader what the .shp coordinates mean. Esri's flavour uses D_WGS_1984 and GCS_WGS_1984 rather than the OGC names and carries no EPSG authority code, so identifying it means matching the datum and spheroid rather than reading an ID.
Three single-part PolyLine records, each carrying its own bounding box, a part index and a run of little-endian coordinate doubles. PolyLine and Polygon share this layout, which is why the shape-type byte in the header is the only thing that distinguishes an open line from a closed ring.
Three Polygon records, one of which has two rings: the Mill Court parcel and its courtyard. Shapefile winds rings the opposite way to GeoJSON (exterior clockwise, holes anticlockwise), and it has no explicit hole marker, so winding is the only signal a reader has.
A zipped shapefile containing the full five-file point set: .shp, .shx, .dbf, .prj and .cpg. Zipping is how shapefiles are actually exchanged, because a bare .shp is meaningless without its sidecars, and it is the upload format most web GIS tools accept.
A zipped shapefile containing a three-file polygon set with no .cpg, so the DBF encoding is undeclared. Zipping is how shapefiles are actually exchanged, because a bare .shp is meaningless without its sidecars, and it is the upload format most web GIS tools accept.
A single WKT value for the Kestrel Bay town centre. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for the four-vertex Coast Road. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for the Mill Court parcel and its courtyard. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for all three parcels in one geometry. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A single WKT value for a point, a line and a polygon in one value. WKT nests with bare parentheses and no type tags on the inner parts, so the number and depth of brackets is the only thing that distinguishes a polygon ring from a multipolygon member, which is where hand-written parsers go wrong.
A point with an explicit Z dimension tag. Some producers write `POINT Z (x y z)` and others write `POINT(x y z)` with no tag at all, so a parser has to cope with the dimension being declared or merely implied by the ordinate count.
A three-vertex line carrying both elevation and a measure, so each position has four ordinates. GeoJSON tops out at three, which makes this the fixture that shows what a WKT-to-GeoJSON conversion has to drop and whether it says so.
PostGIS's extended WKT, which prefixes the geometry with `SRID=4326;`. It is not part of the OGC standard, so a strict WKT parser rejects the whole string, while a PostGIS-aware one gets the coordinate system for free.
Twenty-one raw bytes: a byte-order flag, a little-endian geometry-type code of 1, and two float64 ordinates. This is the wire format PostGIS, GeoPackage and most spatial drivers actually move geometry in.
PostGIS EWKB, where the SRID is carried by OR-ing 0x20000000 into the geometry-type word and appending the code. A strict OGC WKB reader sees type 0x20000001 instead of 1 and either fails or, worse, reports an unknown geometry type.
The reference .prj for this category: WGS 84 geographic in Esri's WKT 1 dialect, which uses D_WGS_1984 and GCS_WGS_1984 in place of the OGC spellings and carries no AUTHORITY node. Everything else in this family is a variation on it.
The same CRS in WKT 2, which renames almost every keyword (GEOGCRS, ELLIPSOID, LENGTHUNIT) and (crucially) declares axis order explicitly with AXIS and ORDER. WKT 1 left that implicit, which is the root of most latitude/longitude swaps.
The projection every web map uses, defined as Esri's Mercator_Auxiliary_Sphere. It treats the ellipsoid as a sphere for the projection maths while keeping ellipsoidal latitudes, which is why it is a pseudo-Mercator and why it cannot represent latitudes beyond about 85.05 degrees.
The UTM zone that actually contains the invented territory: zone 28N, central meridian 15 W. It is a definition fixture only: no projected coordinates are published for it here, because a transverse Mercator value is not something to take on trust from a fixture.
Plate carrée on a sphere of radius 6,378,137 m: the simplest projection with a closed form you can check by hand. That is exactly why it is here: it makes the reprojection pair in this subcategory verifiable with a calculator rather than a library.
The five towns in EPSG:4326: the geographic source, in longitude/latitude degrees. All three files hold the same five places, so reprojecting any one of them and diffing against another scores your transform against a known answer rather than against another implementation of the same library.
The five towns in EPSG:3857: Web Mercator, the projection every slippy map renders in. All three files hold the same five places, so reprojecting any one of them and diffing against another scores your transform against a known answer rather than against another implementation of the same library.
The five towns in EPSG:4087: World Equidistant Cylindrical, whose closed form can be checked by hand. All three files hold the same five places, so reprojecting any one of them and diffing against another scores your transform against a known answer rather than against another implementation of the same library.
Nine control points (the five towns plus Null Island, the equator, a high-latitude point and the Web Mercator latitude limit) with their coordinates in both projections. The two target projections share the x formula and differ only in y, which isolates a latitude-transform bug from a longitude one.
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.
A FeatureCollection carrying the `crs` member from the 2008 GeoJSON specification. RFC 7946 removed it and fixed the CRS as WGS 84, so a modern reader should treat this as an ignorable foreign member, but plenty of exporters still write it and some readers still obey it.
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.
What each decimal place is actually worth on the ground, computed on a sphere of mean Earth radius at the territory's latitude. Longitude degrees are shorter than latitude degrees by the cosine of the latitude, which is why the two columns diverge.
The territory as an OGC GeoPackage: an ordinary SQLite database with the three required metadata tables and three feature layers whose geometry columns hold GeoPackage binary blobs. Unlike a shapefile it carries several geometry types, long column names and real typed columns in one file.
A GeoPackage holding an `attributes` table with no geometry at all: the standard's own answer to a lookup table you want to ship alongside your layers. Its gpkg_contents row has null bounds and a null SRS, which is what readers that assume every row is spatial trip over.
The same five towns stored as projected metres rather than degrees, with EPSG:3857 registered in gpkg_spatial_ref_sys and stamped into every geometry blob's header. Unlike GeoJSON, GeoPackage genuinely supports this, so it is the clean way to test that your reader honours the declared SRS instead of assuming 4326.
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.
GML calls a multipolygon a MultiSurface and its parts surfaceMembers, and nests exterior and interior rings under named elements rather than relying on ring order. This feature holds the holed lake and a solid parcel in one geometry, which is the shape a WFS response usually takes.
Wither Lake and its island as an OSM multipolygon relation: two closed ways tagged separately and joined by a relation whose members carry outer and inner roles. OSM has no polygon primitive at all, so reconstructing the hole means reading the relation rather than the ways.
Real SHP component from the five-town Kestrel Bay shapefile set, copied byte-for-byte into the Convert v2 reserve. Stable P8 artifact p8-convert-shapefile-shp.
Real SHX component from the five-town Kestrel Bay shapefile set, copied byte-for-byte into the Convert v2 reserve. Stable P8 artifact p8-convert-shapefile-shx.
Real DBF component from the five-town Kestrel Bay shapefile set, copied byte-for-byte into the Convert v2 reserve. Stable P8 artifact p8-convert-shapefile-dbf.
Real PRJ component from the five-town Kestrel Bay shapefile set, copied byte-for-byte into the Convert v2 reserve. Stable P8 artifact p8-convert-shapefile-prj.
GeoJSON semantic target for the five-town shapefile set, preserving point order, CODE/NAME/POP/FOUNDED attributes, and longitude/latitude coordinates; the omitted .cpg is safe because every copied DBF value is ASCII. Stable P8 artifact p8-convert-shapefile-geojson.
Every value from the CF-1.8 NetCDF grid flattened to one row per cell, with the axis values spelled out in full. Diff a NetCDF-to-table export against this file to prove the reader walked the dimensions in (time, lat, lon) order and did not silently transpose the array.
The stored integer, the unpacked value, the original float and the quantisation error for all 120 cells of the packed NetCDF grid. It makes the cost of int16 packing explicit and gives an unpacking implementation an exact per-cell target.
A 32-bit integer image carrying a complete tangent-plane WCS: 1-based CRPIX reference pixels, a deliberately negative CDELT1 so right ascension runs the other way, and an ICRS frame. It targets the two mistakes every WCS implementation makes first, the 1-based origin and the flipped axis.
Every header card of the tangent-plane WCS file transcribed to keyword, value and comment columns. Diff a header parser's output against it to prove the parser split each 80-column card at the right places instead of guessing on whitespace.
One array stored twice in the same file: chunked with the shuffle and gzip filters applied, and contiguous with no filters at all. Comparing the two proves a reader ran the HDF5 filter pipeline rather than reading raw chunk bytes.
A MATLAB v7.3 variable store, which is an HDF5 file with a 512-byte MATLAB user block and MATLAB_class attributes: the bytes are the same whichever extension you give it. Because MATLAB is column-major, A appears in HDF5 as its own transpose, which is the conversion bug this fixture is built around.
Every element of the float64 .npy array written as its shortest round-tripping decimal representation, one row per element in C order. Parsing this text back to float64 reproduces the binary array bit for bit, so it is a usable oracle rather than a lossy printout.
An npz-style bundle: a ZIP whose members are .npy files, which is exactly what NumPy's savez produces. np.load opens it by ZIP magic rather than by extension, so the arrays load straight from this .zip; rename it to .npz for tooling that checks the suffix.
The identical five arrays bundled with deflate instead of stored, which is the only difference between NumPy's savez and savez_compressed. Loading both and comparing proves a reader ran the decompressor rather than trusting stored-size shortcuts.
Every value in the float64 boundary array decomposed into its shortest decimal representation, its C99 hexadecimal float form, and its raw sign, exponent and mantissa fields. It turns 'the numbers came back wrong' into a diff you can point at a single bit.
The float32 boundary values split into sign, 8-bit exponent and 23-bit mantissa alongside their decimal forms. Use it to check a single-precision encoder field by field rather than guessing which end of the number went wrong.
The six NaN bit patterns broken into sign bit, quiet bit and payload so the difference between a quiet and a signalling NaN is a column rather than folklore. It is the reference for testing whether a serializer preserves NaN payloads or normalises them all to one canonical pattern.
Each rung of the subnormal ladder with its bit pattern, decimal value, C99 hex float and remaining significant bits, plus the value a flush-to-zero pipeline would produce instead. It makes gradual underflow a table you can diff rather than a behaviour you have to infer.
Twelve doubles narrowed to single precision with the absolute, relative and ULP error of each, plus whether the value survived unchanged. It covers the three distinct ways narrowing fails: rounding, overflow to infinity at 1e39, and demotion to a subnormal at 1e-40.
Every value in the raw endian pair with its exact byte sequence in both orders, so a decoder can be checked offset by offset instead of value by value. Negative zero and the subnormal entries are the rows where a byte-order mistake stops looking like a mistake.
Every element of the synthetic phantom dataset as tag, value representation, meaning and encoded length, in the ascending tag order the standard mandates. Diff a parser's element list against it to check both the ordering rule and the two different length encodings.
Ethanol as a V2000 molfile with fixed-column 3D coordinates, a nine-atom counts line and an eight-bond block. The column widths are part of the format rather than a convention, so it is a genuine test of fixed-width parsing rather than of whitespace splitting.
The same ethanol geometry in XYZ format: an atom count, a free-text comment line and one line of element and coordinates per atom. XYZ carries no connectivity at all, so converting to it from the molfile is a lossy operation that this pair makes measurable.
Ethanol as a single tab-delimited SMILES record, the most compressed member of this family: three heavy atoms with every hydrogen implicit and no geometry whatsoever. Round-tripping molfile to SMILES and back is the classic lossy conversion, and this pair is the reference for it.
An SDfile wrapping the identical ethanol molfile plus five tagged data fields and the mandatory $$$$ terminator. The property block syntax (a header line, a value and a blank line) is where SDfile parsers usually diverge from molfile parsers.
One row per molecule used across the chemistry fixtures, with formula, molecular weight, SMILES and the atom and bond counts each file should yield. It is the oracle a cheminformatics toolkit can be scored against without needing a second toolkit to generate the answers.
The same four contigs written one sequence per line rather than wrapped, which is how many pipelines emit FASTA and how many line-oriented parsers assume it always looks. Comparing against the wrapped twin proves a parser joins continuation lines instead of taking the first one.
The identical reads and identical quality scores written with the legacy Phred+64 offset used by older Illumina pipelines. Decode it with the modern offset and every base looks 31 points better than it is, which is a silent quality inflation rather than a parse failure.
Every twelfth base of the six reads with its Phred score, the ASCII character it takes under both offsets, and the error probability that score implies. It converts a quality-encoding argument into a lookup you can diff.
Every interval written in both coordinate conventions with its length, which is identical either way. It is the lookup table for the most common bioinformatics off-by-one, and the length column is what proves a conversion did not quietly change an interval's size.
Each alignment's CIGAR decomposed into how many query bases and how many reference bases it consumes, with the resulting 1-based reference end. The three records where those numbers differ are the whole reason CIGAR arithmetic is worth testing.
The identical tree topology with every branch length and support value stripped, which is what a Newick writer produces when the source tree has no lengths. Comparing the two proves a parser distinguishes 'length zero' from 'no length recorded'.
The twelve stored entries of the sparse matrix with both 1-based and 0-based indices in adjacent columns. It turns the Matrix Market indexing convention from a footnote into something a loader can be diffed against directly.
Valid HDF5 hierarchy source with raw, processed, and metadata groups plus four unit-tagged datasets for Convert v2. Stable P8 artifact p8-convert-hdf5-source.
JSON decoded-result reference for the HDF5 hierarchy and its normalisation invariant, kept beside the binary source for semantic rather than byte-level comparison. Stable P8 artifact p8-convert-hdf5-expected.
JSON Schema reference that validates the HDF5 decoded-result contract, kept beside the binary source for semantic rather than byte-level comparison. Stable P8 artifact p8-convert-hdf5-schema.
CSV reference listing the four expected HDF5 datasets with shapes and units for lightweight converter assertions. Stable P8 artifact p8-convert-hdf5-summary-csv.
An Argo Workflows DAG template carrying the same six-task ETL topology as the Airflow, Graphviz and Mermaid fixtures in this category, so a converter or visualiser can be scored against one known answer across four formats.
Argo's steps template, whose double-nested list is a genuine parser trap: the outer list is sequential and the inner list is parallel, so a reader that flattens it reports four sequential steps instead of three groups.
An Airflow DAG definition in the classic operator style, using only the no-op EmptyOperator so the file describes a topology and performs no work. Carries the six-task ETL graph shared across the Airflow JSON, Argo, Graphviz and Mermaid fixtures.
A decorator-based Airflow TaskFlow DAG where dependencies are implied by function calls rather than >> operators: the shape static DAG extractors most often get wrong. Every task returns a literal, so nothing performs I/O.
The serialized-DAG shape Airflow stores in its metadata database, as standalone JSON: per-task metadata with explicit downstream_task_ids. Carries the same six-task topology as the Python, Argo, Graphviz and Mermaid fixtures.
The shared six-task topology as a plain node/edge JSON document that also publishes the expected answers (roots, leaves, longest path, and topological order), so a graph library or DAG visualiser can be scored without a hand-written oracle.
A CWL Workflow carrying the same six-step ETL topology as the Airflow and Argo fixtures, with dependencies expressed as step output references and a multi-source input resolved by pickValue. For cross-format DAG conversion tests.
CWL scatter in both forms: a single-parameter scatter over an array input, and a two-parameter scatter with scatterMethod flat_crossproduct. The scatter dimensionality is what distinguishes correct CWL engines from approximate ones.
The shared six-task ETL topology as a Graphviz digraph, with node and edge defaults, per-node attribute overrides, a same-rank constraint and C-style comments. Carries the identical graph to the Airflow, Argo, CWL and Mermaid fixtures.
The same topology plus one back edge, so the graph is deliberately not a DAG. A renderer must still draw it and a scheduler must reject it, which is why this is a reference fixture rather than a corrupt file.
The shared six-task ETL topology as a Mermaid flowchart, with mixed node shapes, a subgraph, a classDef and %% comments. The Mermaid twin of the Graphviz fixture, for scoring diagram-format converters against one known answer.
A Mermaid stateDiagram-v2 describing environment promotion with canary and rollback transitions, start and end pseudostates, and a note block. A second Mermaid diagram type, so a renderer is not only tested on flowcharts.
