Convert SAV to CSV without SPSS — and know what you're losing.
Drop your .sav below and it is read here, in this tab. First you see which SPSS-only details a CSV cannot carry out of your file — then you convert it, without picking it again.
What a CSV can't carry out of a .sav file
An SPSS file is not a table. It is a table plus a dictionary: for every column it also stores what the numbers mean, which numbers don't count as real answers, and a human description of the variable. A CSV is only the table. Everything in that dictionary has to be either translated, or dropped, and most converters never tell you which happened.
That is what the checker above is for. It reads your file's dictionary and reports the four constructs that decide whether the CSV still means what the .sav meant — including the parts it cannot do anything about. It is not an exhaustive dump of every byte of SPSS metadata: display formatting, column widths and measurement level also go, they just do not change your answers. Once you know what your file carries, the SPSS .sav to CSV converter is where you pick a mode and write the file out.
Value labels: kept, and yours to choose
A coded variable stores 1 and 2 alongside a lookup saying 1 is "Male" and 2 is "Female". Reading that lookup and applying it is the part cheap converters skip, which is why their output is full of bare digits. Here you pick: readable text, the original codes, or both as two columns so each row keeps its code and its meaning together. What no CSV mode can carry is the lookup table itself — a label for a code that never appears in your data has nowhere to live.
Declared missing values: the one that quietly ruins results
In SPSS a variable can declare that 98 means "don't know" and 99 means "refused". SPSS excludes those from every mean it computes. A CSV has nowhere to record that fact, so in codes mode 98 and 99 arrive as ordinary numbers — and the first average you take is wrong, badly, without anything looking broken. In label mode there is a subtler version of the same trap: if the sentinel also has a value label it exports as Refused, which reads fine and is still not an answer. This converter does not silently blank either form out, because guessing which codes are sentinels would be worse. It tells you which variables declare them, and whether those codes are labelled, so you can filter them yourself.
Date variables: a large number, not a date
SPSS stores calendar dates as the number of seconds since 14 October 1582. A field showing "23-JUN-2024" in SPSS is really 13 938 480 000 in the file, and that is what reaches the CSV. To recover the date, divide by 86 400 for days and offset from 1582-10-14 — or subtract 12 219 379 200 to land on an ordinary Unix timestamp.
Watch the format family before you apply that. TIME and DTIME are durations, not instants — elapsed seconds, with DTIME carrying a whole-day part — and WKDAY and MONTH are plain ordinal numbers. Offsetting any of those from 1582 gives you a confidently wrong date. The checker separates the two groups for exactly this reason.
Now convert it
Pick how you want the coded variables written and download the CSV. Check a file above and it loads here automatically.
Questions
Can I convert a .sav file to CSV without SPSS installed?
Yes. A .sav file is a documented binary format, so it can be read without SPSS at all. This page reads yours directly in the browser tab — no licence, no install, no upload. One limit worth knowing up front: ZLIB-compressed .sav files (the "compressed" save option in newer SPSS versions) are not supported yet and will tell you so rather than fail quietly. Re-save without compression, and everything else comes across.
What actually gets lost converting SAV to CSV?
The things that change what the data MEANS are declared missing values (SPSS knows 99 means "refused to answer"; a CSV just sees 99) and date variables (SPSS stores those as seconds since 1582-10-14, and that raw number is what lands in the CSV). Losing less: variable descriptions, since the CSV header uses the short column name, and SPSS display formatting like decimal places and column widths, which a CSV has nowhere to record. Value labels are the one thing that survives on your data — every coded value comes out as text, as a code, or as both — though the lookup table itself does not, so a label for a code that never appears in your rows has nowhere to go. Run your own file through the checker above to see which of these actually apply to it.
Is it safe to convert confidential survey data this way?
The conversion runs in your browser using local JavaScript; the file is never uploaded to a server, so it does not leave your machine. That matters for data under an ethics approval or an NDA, where uploading to a third-party converter is often not permitted in the first place. You can verify it by opening your browser dev tools Network tab while converting — there is no request carrying the file.
Why do my numbers look wrong after converting without SPSS?
Almost always one of two causes. Either you exported numeric codes when you wanted labels (1 instead of Male) — switch the label mode below. Or you averaged a column that still contains declared missing codes such as 98 and 99, which inflates the result badly. Note that in label mode a missing code that also has a value label exports as that text ("Refused"), so it stops looking like a number but still is not a real answer. The checker above lists exactly which variables declare missing values, and whether those codes are labelled.
Do I need PSPP or R to do this properly?
Not for a straight conversion — those are worth installing when you want to keep doing statistics on the file, not when you just need the data out. If you do want the full picture on the non-browser routes, the separate guide on opening a .sav file without SPSS covers PSPP, R haven and Python pyreadstat with the trade-offs of each.