Images, audio, video, and documents with documented metadata paired with deliberately stripped versions, for verifying extraction, preservation, redaction, and privacy-scrubbing behavior.
A JPEG carrying rich EXIF metadata (camera make/model, software, artist, copyright, timestamp) — paired with an identical metadata-stripped copy for testing EXIF reading and privacy-scrubbing tools.
The same photo with all EXIF metadata removed — the stripped twin of the EXIF-present JPEG, for verifying that a metadata-scrubbing tool actually removed everything.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
A package document whose title and creator carry precomposed accents, a combining ring above a bare letter, and a typographic apostrophe. For testing normalisation, sorting and filename derivation - the combining mark is the one that breaks naive length and comparison code.
Every non-ASCII character in the metadata is written as a hexadecimal numeric character reference, so the package document is pure ASCII on disk while the title is Han and Cyrillic once parsed. For testing tools that read metadata with a regex instead of an XML parser.
The package document is encoded as UTF-16 little-endian with a byte order mark while the content documents stay UTF-8 - a combination EPUB permits and almost nothing tests. For finding the parser that opens the OPF as UTF-8 and sees a file full of null bytes.
A title containing two characters above the Basic Multilingual Plane - a blue book and a musical clef - plus a Japanese description. Anything that counts characters as UTF-16 code units, or truncates a title to a byte length, splits a surrogate pair here.
The package document, the navigation document and the chapter each begin with a UTF-8 byte order mark before the XML declaration. Legal, and the classic reason a strict parser reports content before the prolog on a file that looks perfectly fine in an editor.
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.
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.
An EPUB 3 carrying the accessibility metadata distributors now require: schema:accessMode, accessModeSufficient, four accessibilityFeature values, a hazard statement, a written summary, and a dcterms:conformsTo link. The claims are true of the file, so a checker can verify rather than take the metadata's word.
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 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.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
The fully authenticated baseline: SPF pass, DKIM pass, DMARC pass with aligned domains, under a p=REJECT policy. The DKIM signature is a visible SAMPLE placeholder, so the header parses and reports pass but will never verify cryptographically.
The failing twin of the all-pass fixture, headers otherwise identical: SPF fail, DKIM fail with a quoted reason property, DMARC fail under p=REJECT. The quoted reason string contains a semicolon-free phrase specifically to test method-splitting.
SPF passes and DKIM passes, yet DMARC fails — because the signing domain is the relay's, not the From domain's, and the policy demands strict alignment. Any dashboard that reports authentication by reading dkim= alone shows this message as trustworthy.
A mailing-list post carrying three Authentication-Results headers stamped by three different hosts, where DKIM passed upstream and failed at the final hop after the list rewrote the message. Only the topmost header, from the receiving host, may be trusted.
Two DKIM-Signature headers for the same message — the RSA/Ed25519 double-signing used during algorithm migrations — with an l= body-length tag on the first. l= means only the first 120 octets are covered, so anything appended afterwards still verifies; both values are SAMPLE placeholders.
A forwarded message carrying a two-instance ARC chain — Seal, Message-Signature and Authentication-Results at i=1 and i=2 — where DKIM broke in transit but ARC records that it passed upstream. Every seal is a visible SAMPLE placeholder, not real cryptography.
A sample machine-discoverable Do Not Track policy of the kind served at /.well-known/dnt-policy.txt, stating retention windows, exceptions and a contact for a fictional site. For testing crawlers and privacy scanners that look for the document and read its version header.
Host metadata in its original XRD form: a subject, an alias, an expiry, one property, and three Link elements including an lrdd template with a {uri} placeholder. Paired with the JRD twin that carries exactly the same data.
The JSON Resource Descriptor twin of the XRD host-meta: identical subject, alias, expiry, property and three links, expressed with lower-case JSON member names. For testing XRD-to-JRD conversion against a known answer.
The baseline every canonical audit should pass: one self-referential canonical, an indexable robots meta, matching hreflang self-reference and an og:url that agrees with all of them. For use as the comparison reference against the conflicting pages in this set.
Page A of a deliberately invalid two-page canonical loop: A declares B canonical while B declares A canonical, so no page in the pair is its own canonical. For testing that a crawler detects the cycle instead of following it forever.
Page B of the deliberately invalid canonical loop, closing the cycle by naming page A as its canonical. Ships with page A so the loop can actually be traversed rather than described.
A deliberately invalid page carrying two canonical tags in the head and a third in the body. Search engines ignore body-level canonicals entirely and treat multiple head-level ones as a conflict. For testing that an extractor reports position as well as value.
A page that names itself canonical while telling robots not to index it, and then contradicts that again with an agent-specific googlebot meta that permits indexing. For testing directive precedence when a page argues with itself.
A valid Product record with a nested Offer carrying price, currency, availability, condition and shipping details, plus an AggregateRating. For testing rich-result validators and structured-data extractors against a document that should pass cleanly.
A valid NewsArticle with two authors, a publisher whose logo carries explicit pixel dimensions, three images at the aspect ratios news results expect, and both publication and modification timestamps. For testing article extraction and date normalisation.
A valid Event record for a hybrid event: both a physical Place with a postal address and geo coordinates and a VirtualLocation, plus a free Offer and a capacity. For testing array-valued properties and event date/timezone handling.
A valid Recipe with ISO 8601 durations, four ingredients, and instructions that mix flat HowToStep nodes with a nested HowToSection. For testing duration parsing and recursive instruction extraction.
A valid LocalBusiness (as a SportingGoodsStore subtype) with a postal address, geo coordinates, weekday and Saturday opening hours, and a 00:00-00:00 specification marking a holiday closure. For testing opening-hours parsing and the closed-all-day convention.
A single @graph holding four nodes wired together by @id rather than by nesting - the shape most CMS plugins emit - including a SearchAction, a breadcrumb whose last item has no URL, and one reference to a product node that lives on another page. For testing graph flattening and reference resolution.
A deliberately invalid Product record: no name, an Offer with a currency but no price, a brand with no @type, a Review with no rating, an AggregateRating with no ratingValue, and an availability given as a bare token instead of a schema.org URL. Valid JSON throughout, so the failure is semantic.
A deliberately invalid Recipe carrying six unambiguously wrong-typed values - a numeric datePublished, a prose prepTime where an ISO 8601 duration belongs, an object recipeYield, two non-numeric ratings and a misspelled @type - plus a relative @context that never resolves, an untyped image object and two ingredients crammed into one string. For testing the limits of type coercion.
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.
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.
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.
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 `index` line abbreviates both blob ids to seven characters, which is what plain format-patch emits and what most patches in the wild carry. Three-way application can still fall back to path matching, but the blobs cannot be looked up unambiguously in a large repository.
The same patch with `--full-index`, so both blob ids are the complete 40 hex characters. This is what `git apply --3way` needs to find the pre-image blob, and comparing the two twins shows a parser must accept any hash length between 4 and 40.
The stable machine format of git blame: a full header block the first time a commit appears and a bare `<sha> <old> <new>` line every time after, with each source line following on a tab-prefixed line. A parser that expects the header on every group loses the author of every line after the first.
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 metadata endpoint's response, where each metric name maps to a list because different targets can disagree. http_requests_total here has two conflicting HELP strings — the real-world state that a metric catalogue or documentation generator has to resolve rather than assume away.
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.
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 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 2.3 JSON SBOM that uses the snippet section to attribute a fictional vendored fragment inside a file to a different licence, with both byte-offset and line-number ranges. Every package, version, hash and licence is fictional — the tree describes nothing real.
The plain build record a CI job writes next to its artifacts — source ref and commit, builder identity, timings, toolchain versions and output digests — from which a provenance statement can be generated. Every package, version, hash and licence is fictional — the tree describes nothing real.
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.
RFC 7946 section 6 allows members it does not define to sit alongside the ones it does, and requires parsers to ignore rather than reject them. This collection carries three such members at the top level.
The five towns with a four-element bounding box on the collection, ordered west, south, east, north as RFC 7946 requires. The values are the true extent of the contained points, so a reader that recomputes the box can be scored against the declared one.
Three features that each carry their own bbox. Spatial indexes are often built from these declared boxes instead of the geometry, so a wrong or stale one produces a query that silently misses features.
Five features whose `id` is a string and sits on the Feature itself rather than inside `properties` — the placement RFC 7946 specifies and the one most CSV-shaped importers get wrong by flattening it into an attribute.
The same five towns keyed by numeric ids. RFC 7946 allows an id to be either a string or a number, and code that assumes one type breaks on the other — usually by stringifying 1 into "1" and then failing to match on a later join.
Five town geometries that each carry both an `id` member and a `properties` object. TopoJSON keeps these separate, and converters that fold the id into properties (or drop it) break joins against an external attribute table.
Eight trackpoints each carrying a Garmin TrackPointExtension with heart rate, cadence and air temperature. The GPX schema deliberately leaves `extensions` open, so this is the fixture for checking that a reader surfaces vendor data instead of discarding it on export.
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.
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.
The same five towns with a declared `Schema` and typed `SimpleData` values — KML's answer to untyped ExtendedData. Pair it with the untyped fixture to check that your importer prefers a declared type over a guessed one.
Four Placemarks with a `TimeSpan` and one with an instantaneous `TimeStamp`, which is what drives the time slider in a globe viewer. Time is the first thing a KML-to-GeoJSON conversion drops, because RFC 7946 has no place to put it.
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.
A one-line sidecar naming the encoding of the .dbf. Without it a reader has to guess — usually cp1252 — and every non-ASCII attribute value comes back as mojibake, which is the single most common shapefile data-loss bug.
The sidecar that declares `attributes-utf8.dbf` as UTF-8. Note that the DBF also carries a language-driver byte in its header, and the two can disagree — which is exactly the ambiguity a reader has to resolve and document.
The sidecar that declares `attributes-cp1252.dbf` as ISO-8859-1. Note that the DBF also carries a language-driver byte in its header, and the two can disagree — which is exactly the ambiguity a reader has to resolve and document.
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.
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.
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.
CUE sheet 01 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-01.
CUE sheet 02 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-02.
CUE sheet 03 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-03.
CUE sheet 04 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-04.
CUE sheet 05 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-05.
CUE sheet 06 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-06.
CUE sheet 07 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-07.
CUE sheet 08 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-08.
CUE sheet 09 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-09.
CUE sheet 10 with two deterministic track indices and a stable companion filename for edit-list parser tests. Stable P8 artifact p8-audio-edge-cue-10.
JSON edit metadata fixture 01 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-json-01.
JSON edit metadata fixture 02 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-json-02.
JSON edit metadata fixture 03 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-json-03.
JSON edit metadata fixture 04 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-json-04.
JSON edit metadata fixture 05 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-json-05.
TXT edit metadata fixture 01 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-txt-01.
TXT edit metadata fixture 02 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-txt-02.
TXT edit metadata fixture 03 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-txt-03.
TXT edit metadata fixture 04 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-txt-04.
TXT edit metadata fixture 05 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-txt-05.
YAML edit metadata fixture 01 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-yaml-01.
YAML edit metadata fixture 02 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-yaml-02.
YAML edit metadata fixture 03 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-yaml-03.
YAML edit metadata fixture 04 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-yaml-04.
YAML edit metadata fixture 05 with three millisecond offsets, an explicit crossfade, and a preserve-channel policy. Stable P8 artifact p8-audio-edge-yaml-05.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
