Many valuable datasets never leave a researcher's hard drive. They were collected carefully, then used once and forgotten. A data paper solves that problem: a peer-reviewed publication whose purpose is to describe a dataset so thoroughly that other researchers can discover it, judge its quality, and use it with confidence.
This guide explains how to write a data paper from start to finish: deciding whether your dataset deserves one, choosing a repository, documenting methods and metadata, handling licensing and ethics, and surviving peer review. Unlike a research article, a data paper earns its place by making data findable and reusable, not by arguing a new claim. If you are new to publishing generally, start with our guide on how to publish a research paper,
A data paper is a scholarly article that describes a dataset: what was collected, how, where, when, and in what form, with reuse documentation. The dataset itself is deposited in a repository, and the paper points to it through a persistent identifier, usually a DOI.
In short, the dataset is the evidence and the paper is its guidebook. A good guidebook explains instruments, sampling, variables, units, missing values, and limitations, so strangers can reuse the data unaided.
A research article argues a claim: it states a question, analyses data, and interprets the results. A data paper, by contrast, describes a resource. Its contribution is the dataset itself, judged on completeness, clarity, and reusability, not novel findings.
This difference shapes the whole manuscript. A data paper has no results section in the usual sense and no extended discussion of what findings mean. It may show summary statistics to demonstrate soundness, but not a full analysis.
Not every spreadsheet deserves a data paper. A dataset earns one when substantial, original, well documented, and useful beyond its own project. Useful signals include a large or unusual sample, a long time series, a rare setting, or data filling a recognised gap.
Ask three honest questions first. Would another researcher realistically reuse these data, or are they only intelligible inside your own project? Is the dataset complete and final, or still changing every week? Can you document it fully without revealing confidential information? If the first answer is yes and the other two can be managed, a data paper is worth writing.
Some journals specialise entirely in data papers, while others accept them alongside research articles. Read the aims and scope: an ecology data journal will not want a clinical dataset. Check whether the journal requires deposit before submission, which repositories it accepts, and what licence it expects.
Build your shortlist as explained in our guide on how to choose the right journal, and read two or three data papers the journal recently published. Ask whether your dataset resembles them in size and documentation standard.
Choose the repository before you finish writing, because the repository record shapes the paper. Prefer your field's domain repository when one exists. Otherwise a general repository such as Zenodo, Figshare, or Dryad is a sound choice, and your institution may also run its own repository.
Confirm four things: the repository issues a persistent identifier such as a DOI, it allows a clear licence, it supports versioning so corrections can be tracked, and it will preserve the data long term. A personal-drive link is no substitute: such links break and cannot be cited reliably.
Most data journals expect your dataset to follow the FAIR principles: Findable, Accessible, Interoperable, and Reusable. Findable means the data have a persistent identifier and rich metadata so catalogues can surface them. Accessible means the identifier resolves to the data or to clear access instructions.
Interoperable means standard formats and vocabularies, so data can combine with other datasets. Reusable means the licence, provenance, and documentation are clear enough that another researcher can use the data lawfully and correctly.
Metadata are the facts about your data: title, creators, date range, geographic coverage, variables, units, methods summary, licence, and identifier. Good metadata let a researcher judge relevance in minutes, without downloading anything. Write metadata for a stranger: expand every abbreviation, define every code, and state units explicitly.
Alongside the metadata, provide a README file and a data dictionary. The README explains the project and lists every file and how they relate. The data dictionary lists every variable, its definition, its allowed values, and how missing values should be read. See also our guide on how to cite datasets in a research paper.
The methods section must let a reader judge how the data were produced and whether they can be trusted. Describe the study design, sampling or collection procedure, instruments and settings, time period and location, and any calibration steps. Where data derive from earlier sources, say so: that chain is provenance.
Be specific about processing, in the order it happened. What was removed, recoded, aggregated, or imputed, and why? Name software with its version, and describe any human classification and its consistency checks. Saying data were collected "following standard procedures" tells reviewers nothing.
Clean the data before deposit, not after. Check for duplicate records, impossible values, inconsistent codes, and mismatched units across files, and confirm that dates, coordinates, and identifiers use one consistent format. Document cleaning changes and keep raw files separate, so the trail stays visible.
Then run the checks a reviewer would run. Do row counts match the paper's description? Do summary statistics look plausible? Do records sampled at random read sensibly? Small checks catch errors such as a shifted column, and your checks should be reported in the paper.
Every dataset needs a licence, stated in both the repository record and the paper. For most research data, the most open licence your funder, institution, and ethics approval allow is best, commonly CC0 or CC BY 4.0. Without one, reuse is legally unclear and careful researchers will avoid the data.
Ethics come first where people, animals, or sensitive locations are involved. Confirm consent and ethics approval permit sharing, anonymise personal data, and suppress identifying variables. Where open sharing is not possible, describe the restriction honestly and explain how qualified researchers may apply for access.
The data availability statement is a short paragraph stating where the data are, how to find them, and under what conditions. A strong statement names the repository, gives the persistent identifier or DOI, and states the licence — for example, that the dataset is openly available in Zenodo under CC BY 4.0, followed by the DOI link.
Avoid vague statements such as "data are available on request" with no contact, procedure, or timeframe, since many journals now treat that as insufficient. If access is restricted, say who may request it and under what conditions; if embargoed, give the end date.
Follow the target journal's structure, but most data papers share the same shape. The title should name the dataset's scope — subject, region, period — not a finding. The abstract should summarise what the dataset contains, how it was collected, and why it is useful,
The introduction explains the gap the dataset fills and who might reuse it, without arguing a research claim. The methods section is the heart of the paper and deserves the most space. Data records describe files and variables; validation reports quality checks; usage notes give guidance and limitations.
Figures in a data paper illustrate the dataset, not an argument: a map of sampling locations, a timeline of collection periods, or a chart of variable coverage helps a reader grasp scope at a glance. Tables summarise files and statistics; every figure and table needs a self-contained caption with units defined.
Example uses are especially persuasive. Show one small, concrete analysis or visualisation made from the data, with the steps needed to reproduce it. This proves the data work and gives users a starting point — but keep it brief and illustrative.
Review of a data paper differs from review of a research article because reviewers inspect the data, not just the text. Expect them to download the files, check that documentation matches the deposit, test whether variables are defined, and look for errors or gaps. A reviewer who cannot open a file will ask for fixes before recommending acceptance.
Prepare by reviewing your deposit as a stranger: download it fresh and try to understand one file from the README alone. For background on review models, see our explainer on double-blind peer review explained. Respond to reviewers point by point, stating exactly which file or documentation line you changed.
Cite the dataset wherever it is used, including in your own later papers, using the repository citation with its DOI: creators, year, title, repository name, and identifier. Listing datasets on ORCID and your CV gives them article-like visibility.
Versioning matters because data change. If you correct errors or add records, deposit a new version rather than silently replacing files, and note what changed. The data paper should state which version it describes, so earlier citations stay valid.
Several mistakes recur, and all are avoidable: describing the dataset so briefly that nobody can reuse it; presenting a full analysis instead of describing the data; depositing data in undocumented formats or files whose column headings only the authors understand; and promising open access with a broken link or missing licence.
Another frequent mistake is overstating what the data can support. If the sample covers one region and one season, say so plainly rather than implying broader coverage. Reviewers treat honest limits as a strength. A final read-through against the deposited files catches most problems before submission.
Run through this checklist on the final manuscript and the deposited files together, not on either alone. Confirm the dataset is deposited, the identifier resolves, and the licence is stated in both places. Confirm every mentioned file exists, every variable is defined, and every number matches.
Confirm that methods, provenance, and processing steps are described in enough detail for evaluation, that quality checks are reported, and that ethics and consent conditions are satisfied. Confirm the availability statement is verifiable, no analysis belongs in a research article, and contributors are acknowledged. Finally, ask a colleague unfamiliar with the project to read the paper alongside the deposit and flag anything they cannot follow; their confusion predicts a reviewer's.
| Repository | Best for | Identifier and licence |
|---|---|---|
| Zenodo | General research data of any discipline | DOI; flexible licence choice |
| Figshare | General data, figures, and supplementary files | DOI; flexible licence choice |
| Dryad | Data behind published research | DOI; CC0 as standard |
| Domain repository | Field-specific data | DOI or accession number; field norms apply |
| Institutional repository | Institution-mandated data | DOI or handle; institutional policy applies |
If your dataset is ready to share: Submit your manuscript ← Back to GAP Insights
These authoritative external resources explain the standards and tools mentioned in this guide:
Can I publish a data paper and a research article from the same dataset?
Yes, in most cases. The data paper describes and documents the dataset itself, while the research article presents the analysis and interpretation. Cite the dataset in the research article, do not duplicate the same text, and check both journals' policies on related publications so the relationship between the two papers is transparent.
Do I need to deposit my data before submitting a data paper?
Usually, yes. Most data journals ask for a repository link or identifier at submission so reviewers can inspect the data. Deposit the data first, obtain a persistent identifier such as a DOI, and include it in your manuscript and data availability statement.
What licence should I use for my dataset?
Choose the most open licence your funder, institution, and ethics approval allow, commonly CC0 or CC BY 4.0 for data. The licence must be stated in the repository record and in the paper, and it should match any conditions attached to the original data collection.
Can a data paper contain analysis or results?
A data paper may include basic validation, summary statistics, and example uses that show the data are sound, but it should not present a full hypothesis test or extended interpretation. That analysis belongs in a separate research article that cites the dataset.
What if my data contain sensitive or personal information?
Do not deposit identifiable personal data in an open repository. Anonymise the data where possible, aggregate or restrict sensitive variables, and follow your ethics approval and institutional rules. Where open sharing is not possible, explain the access conditions honestly in the paper and deposit metadata describing how qualified researchers may request access.
How is a data paper cited, and does it count as a publication?
A data paper is a peer-reviewed publication with its own citation, and the dataset itself can also be cited through its repository DOI. Both citations can be listed on a CV and an ORCID record. Citation practice varies by field and institution, so check how your institution treats data papers, but both the paper and the dataset are citable outputs.