--- title: Export Packages description: What's inside a Preservated bulk export package — record formats, file layout, and how records link to media. section: formats order: 2 updated: 2026-07-11 verified: 2026-07-11 related: [formats, formats/metadata-formats, formats/media-formats] features: [bulk-export] --- # Export Packages An institution admin can generate a bulk export of their collection and hand you the resulting files — this page describes what you'll find inside so you can build an import against it. There's no public endpoint to request an export yourself. Exports are generated from the museum's own admin dashboard, so if you're integrating with a specific institution, ask your contact there to run one and share the download. ## Export tracks Preservated offers three kinds of export, and an institution chooses which one to run: - **Content** — a denormalized, artifact-centric export meant for loading into another system: a different collection-management product, a research dataset, or a spreadsheet. This is almost certainly the one you want if you're building an integration. - **Backup** — a normalized, complete dump of the institution's own data, meant for the institution's own disaster-recovery copy rather than for interchange with another product. - **People/Members** — a flat export of the institution's contact/membership records, meant for a mailing list or CRM. Contains personal information and is generated separately from catalog data. The rest of this page focuses on the **Content** track, since that's the interchange-oriented shape. ## Record formats A Content export is available in several formats, chosen by the institution when they run it: | Format | Shape | | --- | --- | | JSON | Records wrapped in a framing object (metadata about the export, plus a `records` array) | | JSONL | The same records with no frame — one JSON object per line, convenient for streaming | | CSV / TSV | Flattened tabular rows — see "Flattening rules for tabular formats" below | | XML | Either a simple generic `…` structure, or one of the standard metadata formats described in [Metadata Formats](/developers/en-US/formats/metadata-formats) | Every format carries the same underlying fields: a stable record identifier, title, type, date, description, creators, subjects/concepts, places, rights and rights-holder information, the artifact's collection name, its visibility, and (when asset files are included in the export) the filenames and record ids that link a metadata record to its bundled media. ## Flattening rules for tabular formats CSV and TSV can't represent repeated or nested values natively, so multi-valued fields (creators, subjects, places, and similar) are flattened into a single cell: - Multiple values join with a semicolon-and-space delimiter (`; `). - Controlled/authority-backed values can optionally be annotated with their source vocabulary in brackets — for example `Fishing [LCSH]; Boats [AAT]`. - A paired column can optionally be included with the authority URI for each value, in the same order, so you can resolve terms to their source vocabulary programmatically instead of parsing the bracket notation. Cells containing the delimiter, quotes, or line breaks are quoted per standard CSV quoting rules. ## Media files When an institution chooses to include original files, they're bundled alongside the metadata rather than left as separate downloads. Each artifact's record carries the in-archive relative path(s) of its files, plus the corresponding stable asset id, so you can join a metadata row back to its file(s) unambiguously even when filenames repeat across the collection (a very common situation in older archives). Only original master files are included by default; a museum can additionally opt to include lightweight preview images, which are packaged separately from the originals. Large collections may not fit in a single archive. When an export includes a lot of media, the institution's admin can choose to split it into several downloadable parts rather than one unbounded file; a manifest inside the export ties everything together so you know which files live in which part. ## Standards XML The XML output option isn't limited to a generic schema — it can also emit any of the same cataloging standards available through metadata harvesting (Dublin Core, LIDO, CDWA-Lite, MARC21-slim). This gives you a bulk, offline version of the same records you could otherwise harvest live — see [Metadata Formats](/developers/en-US/formats/metadata-formats) and [OAI-PMH Harvesting](/developers/en-US/protocols/oai-pmh). ## AI-generated content Institutions can choose to include AI-generated fields (for example an AI-written description, suggested tags, or OCR text) in a Content export. When present, these are clearly namespaced separately from human-entered fields so you can tell curator-authored data from AI-derived data.