“Tidy data” is a specific, checkable standard for how a dataset should be laid out before analysis — not a vague call to “keep your data organized.” It comes from statistician Hadley Wickham’s 2014 paper Tidy Data, published in the Journal of Statistical Software (vol. 59, issue 10), and it defines exactly three structural rules a rectangular dataset must satisfy. A dataset that follows them is tidy; a dataset that doesn’t is “messy,” regardless of how clean, accurate, or complete the values inside it are. For a researcher, the practical payoff is direct: a tidy dataset works immediately with standard statistical software, is easier for a collaborator or reviewer to interpret without asking you what a column means, and is the layout most repositories and reuse-focused funder policies implicitly assume when they ask for machine-readable data.
The three rules of tidy data
Per Wickham’s definition, a rectangular dataset is tidy when all three of the following hold at once:
- Each variable forms a column. Every column holds exactly one variable — one thing being measured or recorded — and nothing else. A column should never mix two different measurements, and a single variable should never be split across multiple columns.
- Each observation forms a row. Every row holds exactly one observation: one unit measured at one point in time (or one combination of the conditions that define your unit of analysis, if the design is more complex, e.g. one participant at one visit).
- Each type of observational unit forms a table. If a project involves two conceptually different kinds of units — for example, patients and the clinical visits nested within them — those belong in two separate, linked tables, not flattened into one.
Any dataset that violates one or more of these is “messy” in Wickham’s technical sense, which is a description of structure, not a judgment about data quality or accuracy.
Quick self-check table
| Question to ask of your spreadsheet | If yes | If no |
|---|---|---|
| Does every column contain one and only one variable? | Rule 1 satisfied | Likely wide-format problem — see below |
| Does every row represent one observation? | Rule 2 satisfied | Rows may be aggregating multiple observations, or splitting one across several rows |
| Are column headers all variable names (not values)? | Rule 1 satisfied | Values are being used as column headers — a classic tidy-data violation |
| Is more than one type of unit (e.g. subject and visit, or sample and assay) mixed in the same table? | Split into linked tables | Rule 3 satisfied |
| Are there merged cells, blank rows for spacing, colour-coding used to carry meaning, or notes typed inside data cells? | Fix before analysis — see spreadsheet section below | Good |
Wide vs. long data: the most common tidy-data violation
The single most common way research data ends up untidy is wide format: repeated measurements of the same variable are spread across multiple columns instead of stacked into rows. This layout is intuitive to build by hand and easy to read at a glance, which is exactly why it’s the default shape researchers reach for in a spreadsheet — and exactly why it breaks Rule 1.
Wide (untidy for analysis) — one row per subject, one column per time point:
| subject_id | bp_week1 | bp_week4 | bp_week8 |
|---|---|---|---|
| P001 | 128 | 124 | 119 |
| P002 | 135 | 130 | 126 |
Here, bp_week1, bp_week4, and bp_week8 are not three variables — they’re one variable (blood pressure) at three levels of a second variable (time), encoded into the column headers themselves. That’s the violation: a value (“week 1”) has been used as a column name.
Long (tidy) — one row per observation, with time as its own variable:
| subject_id | week | bp |
|---|---|---|
| P001 | 1 | 128 |
| P001 | 4 | 124 |
| P001 | 8 | 119 |
| P002 | 1 | 135 |
| P002 | 4 | 130 |
| P002 | 8 | 126 |
The long version satisfies all three rules: subject_id, week, and bp are each a column; each subject-week combination is its own row. It’s also what every mainstream statistical package (R, Stata, SPSS, SAS, Python/pandas) actually expects as input for repeated-measures models, mixed-effects models, and most plotting functions — wide data typically has to be reshaped into long form before it can be analyzed at all, which is why researchers who start in wide format so often end up reshaping later anyway. Building the collection instrument in long form from the start, or reshaping once at data-cleaning stage, avoids doing that conversion repeatedly by hand.
Wide format isn’t always wrong to look at — a wide summary table is often the right shape for a printed report or a figure legend. The rule applies to the dataset used for statistical analysis, not to every table a researcher ever produces from it.
Data organisation in spreadsheets: common violations and fixes
Most tidy-data problems in practice aren’t conceptual — they’re spreadsheet habits that make a file look organized to a human while making it unreadable to software. The most frequent ones:
| Spreadsheet habit | Why it breaks tidy data | Fix |
|---|---|---|
| Merged cells (e.g. merging a header across several columns) | Import tools read merged cells as blank in every cell but the first, corrupting the row/column grid | Never merge cells in a data table; repeat the label in every row instead |
| Colour-coding used to convey meaning (e.g. red fill = excluded) | Colour isn’t a data value — it’s invisible to any statistical import and to most repositories | Add an explicit column, e.g. excluded with values yes/no and a reason column |
More than one piece of information in one cell (e.g. "12mg, discontinued") |
Violates Rule 1 — the column is no longer one variable | Split into separate columns: dose_mg, status |
| Blank rows or columns used purely for visual spacing | Import tools may treat them as missing observations or split the sheet into unintended blocks | Remove them; use a separate summary sheet if you need visual grouping |
| Multiple header rows, or headers that aren’t in row 1 | Breaks any tool that assumes row 1 = variable names | One header row, one variable name per column, data starts immediately below |
| Notes, totals, or averages typed into the same sheet as raw data | Summary rows/columns get read as though they were additional observations or variables | Keep raw data and derived summaries in separate sheets or files |
Inconsistent codes for missing data (blank, NA, -99, n/a used interchangeably) |
Software can’t tell whether these all mean “missing” or are distinct values | Pick one missing-data code, document it in a data dictionary, and use it consistently |
| Dates entered as free text, or auto-“corrected” by spreadsheet software | Spreadsheet programs are well known for silently reformatting dates (and gene names) on open/save | Format date columns explicitly as ISO 8601 (YYYY-MM-DD) and verify after every save |
Worked example: turning a messy field sheet into a tidy dataset
Consider a lab’s raw data entry sheet, built for fast entry during data collection:
| Site | Jan-temp | Jan-notes | Feb-temp | Feb-notes |
|---|---|---|---|---|
| Site A | 18.2 | clear | 19.5 (sensor drift, recalibrated) | |
| Site B | 17.9 | 18.1 | rain |
This layout has three separate tidy-data problems at once: month is encoded in the column headers (wide format, violates Rule 1), one cell mixes a numeric value with a free-text note (violates Rule 1 again), and blank cells are being used inconsistently for “no note” versus what could later be mistaken for “no reading.” A tidy version separates each concern into its own column and stacks months into rows:
| site | month | temp_c | note | flag |
|---|---|---|---|---|
| A | 2026-01 | 18.2 | clear | |
| A | 2026-02 | 19.5 | sensor drift, recalibrated | |
| B | 2026-01 | 17.9 | ||
| B | 2026-02 | 18.1 | rain |
Every column is now a single variable, every row a single site-month observation, and the data-quality caveat (sensor drift) is in its own dedicated field rather than embedded in a value — which also makes it possible to filter or flag those rows programmatically instead of having to read every note by eye.
Why this matters beyond convenience
Tidy structure isn’t just a personal-workflow preference — it intersects with obligations most funded researchers already have:
- Data management plans. A data management plan (DMP) commits a project to producing data in a usable, shareable form; a dataset that only its creator can interpret because of ad hoc wide-format encodings or notes buried in cells undermines that commitment even if the values themselves are correct.
- FAIR data. The FAIR data principles ask that data be Findable, Accessible, Interoperable, and Reusable. Interoperability in particular depends on structural consistency — a repository, or another researcher’s script, has to be able to parse the file automatically, which a tidy layout is built to support and a messy one routinely defeats.
- Data dictionaries. Tidy structure (what shape the table takes) and a data dictionary (what each variable means) are complementary, not the same thing — a well-shaped table with undocumented variable names is still hard to reuse, and a fully documented but wide, merged-cell spreadsheet is still hard to import.
- Reproducibility. Analysis code that expects a specific, tidy input structure is far easier for someone else to rerun against the same data than code full of ad hoc reshaping to work around a messy source file — relevant to reproducibility expectations increasingly attached to funded and published work.
- Metadata and reuse. Clean, consistent metadata is easier to generate and validate against a tidy table than against an inconsistently structured one.
Tidy data and statistical software
The tidy-data standard originated in the R community — Wickham built it into the tidyverse packages (particularly tidyr) as a design principle — but the underlying rules aren’t R-specific. Long-format, one-variable-per-column data is also the expected input shape for repeated-measures and mixed models in Stata, SPSS, and SAS, and for most plotting and modelling functions in Python’s pandas. Researchers choosing between statistical platforms for a specific analysis may find it useful to compare R vs. Stata for statistical analysis separately — but the data structuring decisions on this page apply before that software choice, and hold regardless of which package the analysis ultimately runs in.
Frequently asked questions
What is tidy data in research?
Tidy data is a dataset structured according to three rules set out by statistician Hadley Wickham (2014): each variable forms a column, each observation forms a row, and each type of observational unit forms its own table. It’s a structural standard, not a statement about data accuracy or completeness.
What’s the difference between wide and long data?
Wide data spreads repeated measurements of one variable across multiple columns (e.g. a separate column per time point). Long data stacks those same measurements into rows, with the varying condition (e.g. time point) recorded as its own variable. Long format satisfies the tidy-data rules; wide format typically doesn’t, because it encodes a value into a column header.
Is wide-format data ever appropriate?
Yes, for display — a wide summary table is often the clearest way to present results in a report, poster, or figure. The tidy-data rules apply to the dataset used for statistical analysis, not to every derived table produced from it.
Does tidy data mean the same thing as a clean or high-quality dataset?
No. A dataset can contain accurate, error-free values and still be untidy (e.g. correct numbers spread across a wide layout with merged header cells), and a tidy dataset can still contain data-entry errors. Tidiness is about structure; data quality and validation are separate concerns.
Why do spreadsheets cause so many tidy-data problems?
Spreadsheet software is optimized for human readability during data entry — merged cells, colour coding, and multi-column layouts all make a sheet easier to scan by eye, but each of those conveniences either hides information from software or spreads one variable across multiple columns, which is exactly what the tidy-data rules prohibit.
Do I need special software to make data tidy?
No. Tidy structure is a property of the table itself and can be built directly in a spreadsheet, a database export, or a script; dedicated tools (like R’s tidyr package) exist to reshape data that’s already been collected in a wide or otherwise messy format, but they’re a convenience for fixing existing data, not a requirement for producing tidy data in the first place.
Last verified 2026-08-16. Primary source: Hadley Wickham, “Tidy Data,” Journal of Statistical Software, Vol. 59, Issue 10 (2014).
