A dataset that no one can navigate five years after the grant closes is not a data management failure of storage or backup — it is a naming and folder-structure failure. Consistent data curation starts with a predictable, machine-sortable file and folder structure, agreed before data collection begins and applied without exception across the whole project team. This guide sets out the conventions that make that possible: what to put in a file name, what to leave out, how to structure folders so the hierarchy itself carries information, and a template you can adapt for a new project’s data management plan.
Quick-reference: the core rules
| Rule | Do | Avoid |
|---|---|---|
| Dates | ISO 8601 order: YYYYMMDD (e.g. 20260816) |
Locale-dependent formats like 08-16-26 or 16.08.26, which sort incorrectly and are ambiguous across US/UK date order |
| Spaces | Underscores or hyphens (site_A, site-A) |
Spaces — some systems and command-line tools split a space-containing filename into two arguments |
| Case | One consistent case style for the whole project (all lowercase is the safest default) | Mixed case relied on for meaning — some filesystems (older Windows/macOS defaults) are case-insensitive, so Data.csv and data.csv can silently collide |
| Special characters | Letters, numbers, underscores, hyphens only | / : * ? " < > | & % # @ $ ! and accented characters — several are reserved by Windows, macOS, or shell syntax and will break scripts or cause outright rejected filenames on some systems |
| Length | Keep the full path (drive + all folders + filename) under roughly 255 characters | Deeply nested folders with long descriptive names at every level — Windows historically enforced a 260-character path limit, and even where it’s since been relaxed, syncing tools and archives still choke on very long paths |
| Ordering | Put the most stable, most-sorted-on element first (project code or date), the most variable element last (version, initials) | Burying the element you’ll actually search or sort by in the middle of the name |
| Versioning | A version number or status flag in the name itself: v01, v02, FINAL |
Relying only on a file system’s “date modified” timestamp, which is lost the moment a file is copied, emailed, or re-downloaded |
Anatomy of a file name
A file name is most useful when it is built from a small, fixed set of elements in the same order every time, separated consistently (commonly by underscores, with hyphens reserved for multi-word values inside a single element). A typical research-data pattern looks like:
[ProjectID]_[Description]_[Date]_[Version].[ext]
Applied to a real example: ECO2026_soil-moisture-siteA_20260816_v02.csv
- Project or study ID — a short, stable code that ties every file back to the grant, IRB protocol, or internal project number. Leading with this element means every file for a project sorts together regardless of what else is in the folder.
- Description — enough to distinguish this file from its siblings (instrument, site, sample, or content type), but not a restatement of information already carried by the folder path. If the folder is already named
site-A, the filename doesn’t need to repeat it. - Date — in
YYYYMMDDorder (see below), representing either the date of data collection or the date of last file modification, whichever the project has explicitly agreed on. State which one in the project’s data management documentation, because the two produce different sort orders for the same file over time. - Version or status — a two-digit version number (
v01,v02) or a status flag (DRAFT,FINAL). Two-digit rather than single-digit numbering matters for the same reason as zero-padding elsewhere:v09sorts beforev10;v9does not.
Why ISO 8601 dates specifically
The International Organization for Standardization’s ISO 8601 date format — YYYY-MM-DD, or YYYYMMDD without separators for filenames — is the convention recommended across research-data-management guidance precisely because it is the one date format that sorts correctly as plain text in any file browser or command-line listing, with no ambiguity between US (month-day-year) and UK/most-of-the-world (day-month-year) date order. A folder of files named report_01-15-26.docx, report_03-02-26.docx, and report_20-01-26.docx mixes three different date conventions in one folder and cannot be reliably sorted or parsed by date at all; a folder using report_20260115.docx, report_20260302.docx, report_20260120.docx sorts correctly by default.
Why no spaces or special characters
Spaces and most special characters cause two distinct classes of problem. First, some command-line tools and older scripts interpret a space as an argument separator, so site A data.csv can be read as two separate arguments (site and A and data.csv) rather than one filename, unless the whole name is manually quoted every time it’s referenced. Second, a specific set of characters is reserved by one or more common operating systems and cannot be used in a filename at all on that system: Windows disallows < > : " / | ? * outright, which means a file created with one of those characters on macOS or Linux may fail to transfer to, sync with, or open correctly on a Windows machine (or vice versa) — a real cross-platform collaboration risk on any multi-institution project.
Folder structure: letting the hierarchy carry information
File naming and folder structure work together, not separately: information that’s stable across every file in a folder (project, site, participant group, instrument) belongs in the folder path, not repeated in every individual filename. A common, effective pattern nests by the most stable grouping first and the most granular unit last:
ProjectID/
raw-data/
site-A/
20260601_instrument1_raw.csv
20260601_instrument2_raw.csv
site-B/
processed-data/
site-A/
site-A_cleaned_v02.csv
documentation/
readme.md
data-dictionary.csv
protocol_v01.pdf
analysis/
scripts/
outputs/
Two structural principles hold across most institutional research-data-management guidance (see, for example, the Digital Curation Centre’s guidance on organizing data as part of its Curation Lifecycle Model, and UK Data Service guidance on file organisation):
- Separate raw from processed data. Raw, unmodified instrument or survey output should live in a folder that is never edited in place; every transformation produces a new file in
processed-data(or equivalent), leaving an unambiguous record of what came directly from data collection versus what has been cleaned, transformed, or derived. - Keep folder depth shallow and names short. Every additional nested folder adds length to the full file path, and very long paths are a real, recurring practical problem — historically a hard 260-character limit on Windows, and still a common source of sync failures in cloud-storage and backup tools even where the OS-level limit has been relaxed. A folder structure four to five levels deep, with short (one- or two-word) folder names, is a safer default than a deeply descriptive hierarchy that tries to encode every variable in the path.
Versioning: name-based or system-based, but not both informally
A project needs one deliberate versioning approach, not an accumulation of files named final, final2, final_REALLY, and final_use_this_one — a pattern common enough in research-data-management training that it is one of the most frequently cited cautionary examples in library and RDM-office guidance. Two workable approaches:
- Name-based versioning — a two-digit version number in the filename itself (
v01,v02, …v12), incremented at each meaningful change, with a superseded version either archived to a dated subfolder or deleted according to the project’s retention policy. This is the more transparent option for teams without dedicated version-control infrastructure, because the version is visible directly in the file listing. - System-based versioning — version control software (Git for code and text-based data; a repository platform’s built-in versioning, such as Dataverse’s dataset versioning, for larger binary datasets) that tracks every change automatically and lets the team recover any prior state without manually renaming files. This scales better for actively co-edited files but requires the team to actually use the tool consistently.
Whichever approach a project uses, it should be stated explicitly in the project’s data management plan rather than left to individual habit — inconsistent versioning across team members is one of the most common causes of a dataset becoming untrustworthy before it ever reaches a repository.
A file-naming and folder-structure template
Most institutional data management plan templates ask for exactly this kind of decision to be documented before data collection starts. A minimal version a project can adapt:
| Element | Project’s decision (fill in) | Example |
|---|---|---|
| File name pattern | [ProjectID]_[Description]_[Date]_[Version].[ext] |
|
| Project/study ID code | ECO2026 |
|
| Date meaning & format | Date of collection, YYYYMMDD |
|
| Case convention | All lowercase | |
| Word separator | Underscore between elements, hyphen within a multi-word element | |
| Versioning approach | Two-digit name-based (v01–v99), superseded versions moved to /archive |
|
| Top-level folder structure | raw-data / processed-data / documentation / analysis |
|
| Where the convention is documented | README at project root, referenced in the DMP |
Documenting the convention matters as much as choosing one: a README file at the root of the project folder that states the naming pattern, the folder structure’s logic, and any abbreviations used turns a scheme that’s obvious to its author today into something a new team member, a repository curator, or the researcher’s own future self can actually interpret without asking. This documentation step is itself part of what CASRAI’s data curation entry describes as “organizing” — imposing a coherent structure and naming convention is one of the concrete actions that distinguishes curated data from a folder of files that merely still exists.
How this fits the wider data management plan
Naming and folder-structure conventions are typically a short, specific subsection of a funder-required data management plan — reviewers checking a DMP for adequacy are looking for a stated convention, not necessarily a particular one, so the main compliance risk is leaving the question unaddressed rather than choosing “wrong.” Establishing the convention at the planning stage, before data collection begins, avoids the far more expensive alternative: renaming and reorganizing an entire dataset retroactively once files already exist under inconsistent names, which is both time-consuming and a common source of broken links in analysis scripts that reference the old names. See CASRAI’s research data lifecycle guide for how this planning step fits alongside collection, description, storage, and reuse across a project’s full lifecycle, and the FAIR dataset checklist for how a consistent naming and folder scheme supports the Findable and Interoperable FAIR principles specifically.
Naming conventions are also a practical prerequisite for the tools covered in CASRAI’s data curation tools guide — a structural validator or repository curation-review step can catch missing or malformed metadata, but it generally cannot repair an inconsistent naming scheme after the fact; that has to be decided and applied by the research team itself, from the start.
Frequently asked questions
What is a good file naming convention for research data?
A good convention is short, consistent, and machine-sortable: a fixed order of elements (project ID, description, date, version), separated by underscores or hyphens, using an ISO 8601 date (YYYYMMDD), lowercase letters, and no spaces or special characters. The specific elements matter less than applying the same pattern to every file in the project and documenting it in a README or the project’s data management plan.
Should dates in file names go year-month-day or month-day-year?
Year-month-day (YYYYMMDD), per the ISO 8601 standard. This is the only common date ordering that sorts correctly as plain text and avoids the US/UK month-day versus day-month ambiguity that other orderings create.
How should I structure folders for a research data project?
Separate raw data from processed/derived data at the top level, keep folder nesting shallow (roughly four to five levels), put stable grouping information (project, site, participant group) in the folder path rather than repeating it in every filename, and keep a documentation folder with a README and data dictionary at the project root.
How do I version research data files without version-control software?
Use a two-digit version number in the filename itself (v01, v02), incremented at each meaningful change, and move superseded versions to a dated archive subfolder rather than deleting them outright. State the approach in the project’s data management plan so every team member follows the same rule rather than improvising labels like “final” or “final2.”
Can I use spaces in research data file names?
It’s best avoided. Some command-line tools and scripts split an unquoted filename containing a space into multiple arguments, which can break automated processing pipelines. Underscores or hyphens achieve the same readability without that risk.
Is there an official standard for file naming conventions?
Not a single universal one — no ISO or funder standard mandates a specific file-naming pattern. What is standardized is the date format (ISO 8601), and most institutional research-data-management offices, the Digital Curation Centre, and funder DMP guidance converge on the same underlying principles (consistency, no special characters, explicit versioning) even though the exact element order is left to each project to define and document.
Last verified: August 2026. ISO 8601 date-format guidance and general naming/folder-structure principles are drawn from widely published, uncontested research-data-management practice (Digital Curation Centre, UK Data Service, and standard institutional RDM office guidance); no single named standard mandates a specific file-naming element order, and this page does not claim otherwise.
