10,000-Row CSV
A CSV with 10,000 data rows — for testing streaming parsers, memory handling, and import performance.
Data files are where parsers quietly break, so this category leans into the edge cases. The CSV set runs from clean to deliberately messy — quoted commas, embedded newlines, ragged rows, semicolon and tab delimiters, a headerless file, a ten-thousand-row file, and a Latin-1 encoded file. JSON comes flat, deeply nested, as JSON Lines, and intentionally invalid for error-handling tests. There's XML, YAML, and a real SQLite database with related tables, plus faker-generated user and order datasets with documented schemas. Each file spells out its exact quirks in the spec, so when your importer chokes you know precisely which case did it.
A CSV with 10,000 data rows — for testing streaming parsers, memory handling, and import performance.
A clean, well-formed CSV with a header and 20 rows — the baseline case for CSV parser testing.
A CSV with no header row — for testing parsers that must infer or be told the column names.
A CSV encoded in Latin-1 (ISO-8859-1) with accented names — for testing encoding detection and mis-decoding (it will look wrong if read as UTF-8).
A deliberately messy CSV: a quoted field with a comma, a quoted field with an embedded newline, escaped double-quotes, and ragged rows with too few and too many fields — the cases that break naïve parsers.
A CSV that uses semicolons as the delimiter (common in European locales) — for testing delimiter detection.
A tab-separated values file with a header and 20 rows — for testing TSV parsing and delimiter handling.
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.
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 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 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 proto3 Protocol Buffers schema with messages, an enum, and a repeated field — for testing protobuf compilers (protoc), codegen, and schema tooling.
A well-formed Atom feed with multiple entries — for testing feed readers and parsers.
A well-formed RSS 2.0 feed with a channel and multiple items — for testing feed readers and parsers.
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 BSON — the binary-JSON encoding MongoDB stores documents in. For testing BSON decoders and JSON↔BSON 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 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.
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.
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 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 same employee table as Apache ORC — the columnar format common in the Hive/Hadoop ecosystem. For testing ORC readers and Parquet↔ORC conversion.
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.
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 deeply nested JSON document with objects inside arrays inside objects — for testing recursive parsing and path access.
A flat JSON array of ten simple objects — the baseline case for JSON parsing and mapping.
An intentionally invalid JSON file with a trailing comma and a missing closing brace — for testing parser error handling and messages. Not valid JSON by design.
A JSON Lines file with one object per line — for testing streaming/newline-delimited JSON parsers.
A draft-07 JSON Schema describing a user object — for testing schema validators and schema-aware tooling.
A newline-delimited JSON (NDJSON) stream of event records — for testing streaming JSON parsers.
A sample docker-compose file defining a web service with Postgres and Redis dependencies — for testing Compose parsers and YAML tooling.
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 environment (.env) file with typical configuration keys and placeholder values — for testing dotenv parsers and config loaders. Contains no real secrets.
A classic INI configuration file with sections and key/value pairs — for testing INI parsers.
A TOML configuration file with tables, inline values, and an array of tables — for testing TOML parsers.
A W3C Web App Manifest (JSON) with name, theme colours, and icon set — for testing PWA install prompts and manifest validators.
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 Graphviz DOT directed graph describing a fulfilment pipeline — for testing DOT parsing, Graphviz rendering, and DOT-to-SVG/PNG conversion.
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 PlantUML sequence diagram of an order interaction (customer, store, warehouse) as diagrams-as-code — for testing PlantUML parsing and diagram rendering pipelines.
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 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 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 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 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 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 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 GeoJSON FeatureCollection with a point, a line, and a polygon — for testing map tools and geo importers.
A GPX track with timestamped trackpoints and elevation — for testing route parsers and mapping tools.
A KML document with named placemarks — for testing Google Earth / mapping importers.
An iCalendar (.ics) file with a single event and CRLF line endings per spec — for testing calendar imports.
A vCard 3.0 contact with name, email, phone, and address — for testing contact importers.
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.
The IoT sensor readings as a JSON array — the format twin of the CSV, for time-series testing.
A structured application log with one JSON object per line at info/debug/warn/error levels — for testing log ingestion.
An nginx combined-format access log with several requests, including a 403 and a 404 — for testing log parsers.
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 50,000-row transactions dataset — an in-repo 'large' fixture for testing streaming CSV parsers, import performance, and pagination. Deterministic (fixed seed).
A MySQL-flavour SQL dump with backtick-quoted identifiers and engine options — for testing SQL importers.
A Postgres-flavour SQL dump with a CREATE TABLE and INSERT statements — for testing SQL importers and migrations.
A product object that deliberately violates the product JSON Schema in five ways (out-of-range id, empty name, non-positive price, wrong boolean type, an extra property) — the negative case for testing validator error reporting.
A product object that conforms to the product JSON Schema — the positive case for testing a JSON-Schema validator.
A JSON Schema (draft-07) describing a product object, with required fields, types, and constraints — paired with a conforming and a deliberately non-conforming instance for testing validators.
The decoded header and payload of the sample JWT as JSON, alongside the public signing secret and algorithm — the ground truth for checking a JWT decoder's output.
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.
A real SQLite database with two related tables — users and orders joined by a foreign key — for testing database importers and SQL tooling.
A well-formed XML catalogue with nested elements and attributes — for testing XML parsers and XPath queries.
A YAML configuration file with nested mappings, sequences, inline lists, and comments — for testing YAML parsers.
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.
The daily OHLCV candles as a JSON array — the format twin of the CSV, for charting and time-series testing.
We use Google Analytics. It sets no analytics cookies until you allow the Analytics category below. See our cookie policy.