Every few years a lab pulls out an old drive and finds files nobody can open. The software is gone, the version is too new or too old, or the one person who knew the settings has left. Format choices feel boring when you make them, and they decide whether your data are usable later. The good news is that a few plain rules cover most projects.
This guide is for researchers who collect or analyze data, and for the librarians and research staff who answer their questions. It sits alongside the guides to organizing your files and choosing a repository, and it feeds straight into the file list in your README.
What makes a format a good long-term bet
A durable format is open, which means its specification is published and anyone can write software to read it. It's widely supported, so many tools already do. It's well documented, and it doesn't depend on a single company's product. Plain text is the extreme case: a CSV file written in 1995 still opens in anything today.
Proprietary formats aren't forbidden. They're often the right working format, because they carry labels, formulas, or layout that open formats lose. The trouble starts when the proprietary file is the only copy.
The two-copy rule
The simplest habit is to keep two versions of anything that matters. The working copy is whatever your tools want, such as an SPSS .sav file with value labels, an R object, or an Excel workbook you edit daily. The preservation copy is an open-format export that you save when a stage of the project is done and deposit with the paper. If the software disappears, the preservation copy still reads. If the export loses something, the working copy still has it, and your README says what was lost.
Recommended formats by kind of data
These are common choices, not a law. Your repository's guidance wins if it differs, and many publish a list of preferred formats.
- Tables and surveys. CSV (comma-separated values), saved as UTF-8. For data with many variables, pair it with a codebook, since CSV can't store variable or value labels. Tab-delimited text is a reasonable alternative if your values contain commas.
- Text and documents. Plain text (.txt) or Markdown for notes and transcripts. PDF/A for fixed documents, which is the archival flavor of PDF. Avoid keeping the only copy of a transcript in a Word file.
- Images. TIFF for scans and microscope images you may need to reprocess. PNG for figures and screenshots. JPEG is fine for viewing, but it throws away information each time it's saved, so don't make it your only copy of anything you measured.
- Audio and video. WAV or FLAC for audio you may reanalyze. For video, pick a widely supported container and keep the original recording. Interview recordings often contain identifying information, so check the de-identification guide before sharing.
- Structured data. JSON or XML for nested records. SQLite is a good single-file option for relational data.
- Large arrays and simulations. NetCDF or HDF5 for gridded and multidimensional data, and Parquet for big tables, since it's compact and keeps column types. These are open, widely read in Python, R, and Julia, and built for size.
- Geospatial data. GeoPackage or GeoTIFF. The older shapefile is everywhere, but it's really a bundle of several files that must travel together, with short column names and a size cap.
- Code. Plain-text scripts in a version-controlled repository, with the language and package versions written down. See the guide to reproducible analysis.
Why Excel is a risky archive
Spreadsheets are fine for typing numbers in. They're a bad place to leave them. Excel can quietly convert values on open: identifiers with leading zeros lose them, long numbers get shortened, and some gene symbols and codes are turned into dates. That last one has been reported in published genetics datasets. Merged cells, colors that carry meaning, and notes typed into the margins look clear to you and read as garbage to a script.
If you do use a spreadsheet, keep one table per sheet, one header row, one value per cell, and no formatting that carries meaning. Then export each sheet to its own CSV before you deposit, and name the files so the sheet is obvious.
CSV is simple, but it still has traps
- Encoding. Save as UTF-8. Otherwise names with accents or non-Latin scripts turn into odd symbols on another machine.
- Dates. Write them as 2026-10-10 (year, month, day). A date like 03/04/2026 means different things in different countries.
- Missing values. Pick one code (blank or NA) and say so in the README. Mixing "N/A", "-", 999, and empty cells in one column causes quiet errors.
- One value per cell. Don't put "12 kg" in a number column. Put the unit in the column name or the codebook.
- Header row. One row, short names without spaces or odd characters, and no repeated headers partway down.
Proprietary statistical files
Stata, SPSS, and SAS files keep labels, which CSV doesn't. So keep them as the working copy and add an open copy. Most statistical packages can export to CSV, and the labels can go into the codebook. Say which software and version wrote the original. Repositories such as ICPSR routinely accept these files and convert them, but you shouldn't rely on that for your own long-term copy.
Before you deposit
- List every file and its format in the README.
- Open each preservation copy in a different program from the one that made it. If it opens cleanly, it's probably fine.
- Check that nothing was lost in the export: row counts, column counts, a few spot values.
- Remove unneeded duplicates and temp files. Don't ship lock files like those starting with ~$.
- Confirm the repository accepts your formats and any size limits. If you're unsure, ask the data librarian. [Placeholder: add the name of your own library's list of preferred formats, if there is one.]
- Think about how long the files need to last. The retention guide covers how long to keep them, and good formats make that realistic.
Where this fits with FAIR
Open, documented formats help with the "interoperable" and "reusable" parts of the FAIR principles. A reuser who can open your file without buying software, and who can see how it was written, can do something with it. That's most of the point.
If you support researchers
A one-page format guide is a useful handout for any campus, because the question comes up every time someone fills in a data management plan. Match it to the formats your repository accepts, and add examples from the fields you serve. I build these as part of a data services engagement, and they work well as a workshop, too.
Common questions
What is the best file format for sharing research data? For tables, a plain CSV in UTF-8 is the safest choice because almost every tool can read it. For text, plain text or PDF/A. For images, TIFF or PNG. For large arrays and models, an open format such as NetCDF, HDF5, or Parquet. Keep a note of the format and version in your README.
Is Excel a good format for research data? It's fine for entry and quick looks, but it's a poor archive. Excel can silently change values (gene names turned into dates, leading zeros dropped), merged cells and colored rows hide meaning, and the format changes between versions. Export each sheet to CSV before you deposit.
Should I keep my SPSS, Stata, or SAS files? Yes, as the working copy, because they hold variable labels and value labels that CSV loses. Also save an open-format copy (CSV plus a codebook) so the data stay readable without the software.
What is a preservation format? A format chosen because it is open, well documented, widely supported, and unlikely to become unreadable. Libraries and repositories keep lists of preferred formats, and the Library of Congress publishes one. Your repository may ask for specific ones.