Croissant is an open, community-developed metadata format from MLCommons for describing machine learning (ML) datasets in a way that makes them directly loadable and usable by ML tools and frameworks, not just discoverable by a human reader. It answers a narrower, more operational question than most research data metadata standards: not just what a dataset is and who made it, but what its features, splits, and labels are, and how to load it into a training pipeline without writing bespoke parsing code for every source.
For research administrators and data stewards working at the intersection of research data management and AI/ML research, Croissant matters because it is rapidly becoming the de facto interchange format between dataset repositories and ML tooling — distinct from, but complementary to, the provenance- and packaging-oriented standards CASRAI already covers, such as RO-Crate and general dataset metadata schemas.
What problem Croissant solves
ML researchers routinely spend disproportionate effort just getting a dataset into a usable shape: locating the actual data files behind a landing page, figuring out which columns are features versus labels, reconciling an undocumented train/validation/test split, and writing one-off loader code per dataset. Because this friction repeats across every dataset a lab or platform hosts, MLCommons — the same industry/academic consortium behind the widely used MLPerf benchmarking suite — convened a cross-industry working group (with participants from Google, Hugging Face, Kaggle, OpenML, and academic partners including King’s College London and Eindhoven University of Technology) to define a shared vocabulary that dataset publishers and ML tooling could both target.
The result, Croissant, is designed around a specific operational bar: a dataset is ML-ready when its metadata is structured enough that a generic tool can load it directly — resolving file locations, identifying fields, and mapping them to the tensors or examples a training or evaluation pipeline expects — without dataset-specific glue code.
Technical foundation: JSON-LD built on schema.org
Croissant is expressed as JSON-LD, extending the existing schema.org Dataset vocabulary rather than replacing it. This is a deliberate design choice with two practical consequences:
- Backward compatibility with web-scale discovery. Because a Croissant record is still valid schema.org
Datasetmarkup, a dataset described with Croissant remains indexable by Google Dataset Search and other schema.org-aware crawlers, the same discovery channel that plain schema.org/Dataset markup already supports. - A shared foundation with RO-Crate. RO-Crate — covered in CASRAI’s own RO-Crate guide — also builds its packaging metadata around schema.org, typically using a
Datasetentity as its Root Data Entity. Croissant and RO-Crate are not competitors so much as siblings built on the same base vocabulary but aimed at different jobs: RO-Crate is a general-purpose research object packaging format (any research output, with strong provenance and workflow support), while Croissant is scoped specifically to making a dataset’s ML-relevant structure — features, splits, labels, record sets — machine-actionable for training and evaluation tooling. A single dataset can, in principle, carry both a Croissant description and an RO-Crate package without conflict, since both extend the same schema.org core.
What a Croissant record actually describes
Beyond the standard dataset-level descriptive fields schema.org/Dataset already provides (title, creator, license, description — the same descriptive core CASRAI covers in Descriptive Metadata for Datasets), Croissant adds ML-specific structural layers:
- Resources — the actual files or distributions that make up the dataset and where to fetch them.
- RecordSets — the structured, ML-facing view of the data: fields, their data types, and how records relate to the underlying resources (for example, mapping a CSV column or an image-folder structure into named, typed fields a loader can consume directly).
- Splits — explicit train/validation/test (or custom) partitioning, so downstream tools don’t have to infer or re-derive a split that the dataset creator already defined.
- Labels and feature semantics — which fields function as inputs versus targets, and how categorical or class labels map to values.
Two extension layers sit on top of this core:
- Croissant RAI (Responsible AI) — an extension vocabulary for documenting provenance, collection methodology, known limitations, and other responsible-AI-relevant context about a dataset, aligned with the broader push (also reflected in CASRAI’s AI training data provenance guide) toward documenting where training data actually came from and under what terms.
- Domain extensions — MLCommons has documented domain-specific extensions (for example, in geospatial and life-sciences contexts) that add vocabulary relevant to those data types on top of the Croissant core, rather than requiring every domain’s needs to be folded into the base specification.
Where Croissant fits in the broader research-data ecosystem
For a research data steward, the practical distinctions worth keeping straight are:
- Croissant vs. general dataset metadata schemas (Dublin Core, DataCite, DDI): those schemas are built for discovery, citation, and long-term preservation across all research data types, largely independent of any particular consumer. Croissant is built for one specific consumer class — ML training/evaluation tooling — and includes structural detail (record sets, splits, feature/label roles) those general schemas were never designed to carry. See CASRAI’s guide to choosing a metadata schema for how these fit together rather than compete.
- Croissant vs. RO-Crate — as above, complementary layers on a shared schema.org base rather than alternatives; RO-Crate packages a research object with provenance, Croissant structures a dataset for ML consumption.
- Croissant and persistent identifiers — Croissant metadata can reference a dataset’s DOI or other persistent identifier as part of its descriptive fields, but Croissant itself is not a PID scheme; it complements PID-based citation and versioning practice rather than replacing it. See CASRAI’s guide on persistent identifiers and citation for AI models and training datasets for the identifier and citation layer specifically.
- Croissant and reproducibility — explicit split and record-set definitions reduce a specific class of reproducibility failure (silently different train/test splits between a paper’s reported results and a re-run), a concern also addressed more broadly in CASRAI’s reproducibility infrastructure guide.
Adoption
Croissant metadata is supported by, or has been adopted for datasets hosted on, major ML dataset platforms including Hugging Face, Kaggle, and OpenML, alongside support from Google Dataset Search — reflecting the working group’s cross-platform origin. Because platform-support details and exact dataset counts change frequently as adoption continues, research administrators evaluating Croissant support for a specific repository or platform should confirm current status directly on that platform and via mlcommons.org/croissant rather than relying on a fixed figure.
Governance
Croissant is developed under MLCommons — the same nonprofit consortium that maintains the MLPerf benchmark suite — through an open, cross-institutional working group with participants from industry (including Google and Hugging Face) and academia. The specification and supporting tooling (including a Python library for reading and validating Croissant files) are published openly, and the format has moved through multiple point releases since its initial release as adoption and use cases have expanded.
Practical takeaway for research data stewards
If your institution or repository hosts datasets that are likely to be used for ML training or benchmarking, publishing a Croissant description alongside your existing metadata (Dublin Core, DataCite, or a domain schema) is a low-conflict way to make that dataset directly consumable by ML tooling, without displacing the metadata you already maintain for discovery and citation purposes — because Croissant extends schema.org/Dataset, it can coexist with, rather than replace, your existing schema.org markup and repository metadata.
Frequently asked questions
Is Croissant a replacement for schema.org/Dataset?
No. Croissant extends schema.org/Dataset with additional ML-specific vocabulary (record sets, splits, feature/label roles); a Croissant record remains valid schema.org markup, so tools and crawlers that only understand plain schema.org/Dataset can still read the parts of it they recognize.
Does Croissant replace RO-Crate?
No. They serve different purposes on a shared schema.org foundation: RO-Crate packages a research object (with provenance and file-level structure) for general reuse, while Croissant structures a dataset specifically for ML loading and training/evaluation workflows. A dataset can use both.
Do I need a specific tool to create a Croissant file?
MLCommons publishes open tooling, including a Python library, for authoring and validating Croissant metadata; several dataset hosting platforms also generate or expose Croissant metadata automatically for datasets they host, depending on the platform’s current level of support.
Does using Croissant require restructuring my existing dataset metadata?
No. Because Croissant builds on schema.org/Dataset, it is typically added as an additional structured-data layer describing a dataset’s ML-relevant structure, rather than a replacement for a repository’s existing descriptive metadata (title, creator, license, and so on).
