SPSS Syntax: Writing Reproducible Analysis Files

An SPSS syntax file (a plain-text .sps file made up of commands like GET FILE, RECODE, and T-TEST) is what makes an SPSS analysis reproducible, because it is the one artefact that records every step in a form someone else can re-run, unlike the point-and-click menu history, which leaves no durable record at all. The fastest way to get a correct syntax file is not to type it from memory: click Paste instead of OK in any SPSS dialog box, and SPSS writes the exact command that dialog would have run into a Syntax Editor window. This guide covers using Paste to build a file command by command, the habits that turn a pasted fragment into a runnable, well-structured .sps file, and the two things — commenting and running from a clean, unmodified dataset — that decide whether the result is actually reproducible or just looks like it is.

Why syntax, not the menu history, is the reproducibility artefact

SPSS’s Data Editor supports two parallel ways of working: the point-and-click dialog boxes (Analyze, Transform, Data) and an equivalent command language typed or pasted into a Syntax Editor window. Both produce the same output. The difference is what survives after the session ends. The menu path leaves a Journal file (recorded automatically at Edit > Options > General, if journaling is even switched on) that logs a rough command trace, but it is not designed to be read, cleaned up, or re-run — it is a debugging aid, not a shareable analysis record. A saved .sps syntax file is different: it is deliberately written, human-readable, versionable, and rerunnable end to end. That is what a journal, a supervisor, or a reproducibility reviewer can actually open and check against your reported results — see CASRAI’s Dictionary entry on reproducibility for how that term is used across the different reproducibility types, and how to write a data availability statement for the companion practice of documenting where the data itself lives.

This matters beyond individual discipline. A syntax file is the concrete, checkable form of what NIH’s rigor-and-reproducibility expectations and most journal data-sharing policies actually ask for: not just a results table, but the exact sequence of operations that produced it. Screenshots of a completed dialog box do not satisfy that; a syntax file does.

Building a syntax file with the Paste button

You do not need to memorize SPSS command syntax to get a correct, working file. Every dialog box in SPSS has a Paste button alongside OK. Set up the analysis exactly as you would to run it normally — select variables, set options, choose statistics — then click Paste instead of OK. SPSS opens (or adds to) a Syntax Editor window and writes the exact command that configuration represents, syntactically correct and ready to run. Nothing executes yet; Paste only writes the command.

Repeating this for each step of an analysis — opening the file, recoding a variable, running a test, requesting a chart — builds a complete syntax file out of steps you already know how to do through the menus, with no separate syntax vocabulary to learn up front. This is also the fastest way to learn the syntax language itself: pasted commands are real, correct examples you can read, adapt, and eventually write by hand for small changes (adjusting a variable list, changing a confidence level) without reopening the dialog at all.

A single pasted command looks like this, generated from Analyze > Compare Means and Proportions > Independent-Samples T Test:

T-TEST GROUPS=group(1 2)
  /MISSING=ANALYSIS
  /VARIABLES=score
  /CRITERIA=CI(.95).

Every SPSS command ends with a period. Options are introduced with a forward slash. Indentation and line breaks are cosmetic — SPSS only cares about the period — but keeping the layout Paste produces makes the file far easier to read back later.

Structuring a runnable file, not just a stack of pasted fragments

A syntax file built purely by pasting one command after another will run, but a file organized into clear stages is what someone else can actually follow and reuse. A structure that holds up across most analyses:

• Data import. A GET FILE='...'. or DATASET NAME command at the very top, pointing at the original data file — see the clean-dataset section below for why this specific step is the one that most determines whether the file is genuinely reproducible.
• Variable preparation. RECODE, COMPUTE, VARIABLE LABELS, and VALUE LABELS commands that turn raw variables into the ones the analysis actually uses, each followed by EXECUTE. so the transformation is applied before anything downstream reads that variable.
• Analysis. The statistical procedures themselves — T-TEST, ONEWAY, REGRESSION, CORRELATIONS, and so on — grouped in the order you report them.
• Output handling. An OUTPUT SAVE or exported tables at the end, if you keep the .spv output file alongside the syntax rather than regenerating it each time.

For a long project, INSERT FILE='...'. lets you chain separate syntax files together — a cleaning file, then an analysis file — run from one master file, rather than one very long script covering the whole project. This mirrors the same organizing logic covered in CASRAI’s file naming and folder structure conventions guide, applied to code rather than data files.

Commenting: the difference between a file that runs and a file someone else can follow

SPSS syntax supports comments two ways, and a reproducible file uses them throughout, not just at the top:

• A line starting with an asterisk is a comment, and like every SPSS command it must end with a period: * Recoding age into three bands for the ANOVA below.
• The COMMENT keyword does the same thing explicitly: COMMENT This file reproduces Table 2.

Neither Paste nor the dialog boxes write comments for you — SPSS has no idea why you chose a given cutoff, exclusion rule, or reference category, only what command you ran. That reasoning only survives in the file if you type it in yourself, immediately, next to the command it explains. In practice this means: a one-line comment before each transformation stating what it does and why (not just what the command already says in its own name), a comment marking where each reported table or figure comes from, and a header comment at the top of the file recording the source data file name, the date, and a one-sentence description of what the file reproduces. A syntax file with no comments still runs; it just stops being useful to anyone — including the researcher who wrote it, six months later — as a record of what was actually done and why.

Running the file end to end

A syntax file is only doing reproducibility work if it can be run from a blank slate and land on the same result. In the Syntax Editor: Run > All executes every command in the file top to bottom in one pass; Run > Selection runs only the highlighted commands, useful while building or debugging a file but not the check that matters for reproducibility. Before treating a file as finished, close SPSS entirely, reopen only the syntax file (not the data), and run it with Run > All. If it errors, stalls on a missing variable, or produces different numbers than before, the file was depending on something in the Data Editor’s prior state that the syntax itself never captured — exactly the gap the next section addresses.

The habit that actually makes it reproducible: running from a clean dataset

This is the single most common way an SPSS syntax file quietly stops being reproducible. It happens like this: a researcher makes a transformation through the menus — recodes a variable, deletes a few rows, filters cases — without pasting that step into the syntax file, then continues pasting later steps from that now-modified Data Editor. The pasted commands are all individually correct, and the file runs without error against today’s in-memory dataset. But the file itself never says the earlier menu-made change happened, so running it from the original data file produces a different result — or the same variable simply does not exist under the name the syntax expects.

The fix is a discipline, not a setting: every syntax file should begin with a command that loads the original, unmodified data file — GET FILE='original_data.sav'. — and every transformation the analysis depends on must appear as a command in that same file, in order, after that line. Nothing that happened only through a menu click, and was never pasted, should be allowed to silently become a precondition for a later step. Practically, this means: keep the raw data file read-only and never overwrite it with edits made in the Data Editor; if you catch yourself making an ad hoc change through a menu mid-session, immediately Paste it into the file rather than continuing and pasting only the next step; and periodically do the full close-and-rerun check from the previous section as a test that the file still stands on its own. A syntax file that only works because of un-recorded state sitting in an open Data Editor window is not a reproducibility artefact — it is a script that happens to run once, on one machine, in one session.

Common pitfalls

• Missing EXECUTE. after a transformation. RECODE and COMPUTE commands are read but not applied until SPSS hits an EXECUTE. or the next procedure that forces a data pass — a syntax file that relies on that implicit trigger instead of an explicit one can behave differently depending on what command happens to come next.
• Multiple open datasets without DATASET ACTIVATE. If a file opens more than one data source, every subsequent command runs against whichever dataset is currently active, and a file that never states which one that is will run against the wrong dataset the moment the open order changes.
• Hard-coded absolute file paths. A GET FILE='C:UsersyournameDesktopdata.sav'. line only runs on the machine it was written on; a relative path, or a CD command at the top of the file, is what makes the same syntax file portable to a co-author or a reviewer.
• Treating the .spv output file as the record. Output viewer files are easy to edit or delete tables from after the fact, invisibly. The syntax file, not the output file, is the artefact that proves what actually produced a given table.

Frequently asked questions

What is SPSS syntax?

SPSS syntax is IBM SPSS Statistics’s command language — plain-text commands, saved as a .sps file, that do everything the point-and-click menus do (loading data, transforming variables, running statistical procedures) but in a form that can be saved, read, versioned, and rerun exactly, unlike the menu actions themselves.

How do I get SPSS to write syntax for me instead of typing it?

Set up any analysis in its normal dialog box, then click Paste instead of OK. SPSS writes the exact, syntactically correct command for that configuration into a Syntax Editor window without running it, so you can build a full file this way without knowing the command language in advance.

How do I run an entire SPSS syntax file at once?

In the Syntax Editor, use Run > All to execute every command in the file from top to bottom in a single pass. Run > Selection runs only the highlighted lines, which is useful while building the file but is not a test of whether the whole file works end to end.

Does a syntax file replace a data availability statement?

No — they document different things. A syntax file records what was done to the data; a data availability statement documents where the data itself can be obtained. Reproducibility in practice usually needs both. See CASRAI’s guide to writing a data availability statement.

Why does my syntax file run fine for me but fail for someone else?

The most common cause is a transformation that was made through the menus and never pasted into the file, so the file only works against the already-modified dataset sitting in your Data Editor. Always test a syntax file by closing SPSS, reopening only the syntax file and the original data, and running the whole file fresh — see the clean-dataset section above.

For the broader picture of what SPSS is and how it fits into a research workflow, see CASRAI’s overview, What Is SPSS?, and for choosing between packages, SPSS vs. R and SPSS vs. Stata. For syntax generated by specific procedures, see CASRAI’s guides to running a t-test, one-way ANOVA, two-way ANOVA, Pearson correlation, normality tests, Cronbach’s alpha, binary logistic regression, and descriptive statistics in SPSS, each of which can be captured as syntax the same way described here.