A .sav file converter to PDF that produces a readable report.
Drop an SPSS .sav file and get a paginated PDF: a variable codebook, then the data table, with the value labels resolved. Parsed and rendered in this browser tab — the file is not uploaded.
What this .sav file converter to PDF puts on the page
Most conversions from .sav exist to move data into another program. A PDF is the opposite job: it exists to be read. So instead of dumping a grid and calling it done, the export is built as a short report in three parts.
The cover sheet
Row count, variable count, how many variables carry value labels, whether the values were written as labels or as the underlying numeric codes, and the date. It also states the row range the document actually contains, so a capped export is self-documenting.
The codebook
One line per variable: the short name, the variable label, whether it is numeric or string, the SPSS print format it was declared with (F8.2, A16, DATE11), the missing values the file declares — a single code like 9, a set, or a range such as 90 to 99 — and every code = label pair the variable defines. This is the part most people are actually after when they search for a printable version of a dataset: something to hand a supervisor or staple into an appendix that explains what the columns mean.
The data table
Landscape A4, header row repeated on every page, alternating row shading, and a page header naming the row range the document contains and which columns this page group is showing. Column widths are measured from the content rather than divided evenly, so a short id column does not get the same space as a long open-text answer.
A page has a fixed width, so a cell longer than its column is shortened and ends in .... That is a real loss, so the widget counts those cells and reports the number after the download — a 400-word open-text response will not survive this format, and you should not find that out by reading the PDF.
When a PDF is the wrong choice
Worth saying plainly, because it will save some people a wasted download: if the next thing that happens to this data is analysis, do not use this page. PDF stores glyphs at coordinates, not columns. Pulling a table back out of one is unreliable, and any numeric precision beyond what is printed is gone. For anything heading into R, Python, Stata, SPSS again, or a spreadsheet, the CSV export is the honest answer.
PDF earns its place when the document is the deliverable — a printed codebook, a dataset description in a methods appendix, an attachment for someone who does not have statistical software and never will.
Two limits worth knowing first
Non-Latin labels get substituted
PDF's built-in Helvetica covers Latin script, accents included. Chinese, Japanese, Greek, Cyrillic, Hebrew and Arabic characters have no glyph in it, so they come out as question marks. Rather than let that happen quietly, the widget counts every substituted character and tells you the number after the download. Those labels are intact in the CSV, XLSX and JSON exports, which are UTF-8.
Row count is a choice, not a cap
The default is the first 1,000 rows, because pagination makes large row counts expensive in a way CSV never is. "All rows" is one click away and there is no server-side ceiling — but the document always prints the range it contains, on the cover and on every data page. A PDF from here cannot look complete while being partial.
Questions
What is actually inside the PDF?
Three parts. A cover sheet with the row count, variable count, how many variables carry value labels, whether you exported labels or codes, and how many rows the document contains. Then a codebook: one row per variable with its name, variable label, type, SPSS print format (F8.2, A16, DATE11), declared missing values, and every code = label pair. Then the data table itself, landscape A4, with the column headers repeated at the top of every page.
Can I get the numbers back out of the PDF later?
Not easily, and that is worth knowing before you pick this format. PDF stores positioned glyphs, not columns — copying a table out of one usually gives you a mangled mess. Use the PDF for reading, printing, emailing to a supervisor, or dropping into a thesis appendix. If the file is going into R, Python, Stata or Excel, take the CSV or the .xlsx instead.
Do non-English variable labels survive?
Latin-script ones do; others are substituted and the tool tells you how many. PDF's built-in Helvetica uses the WinAnsi character set, which covers English, French (œ and Œ included), German, Spanish, Italian, Portuguese and Nordic text, plus typographic quotes, dashes and the euro sign. Greek, Cyrillic, Chinese, Japanese, Hebrew and Arabic have no glyph there, so those characters are replaced with a question mark and the widget reports the exact count after the download. Nothing is substituted in the CSV, XLSX or JSON exports, which are UTF-8.
What happens with a dataset that has 80 variables?
The table is split into column groups. As many columns as fit across a landscape page are printed for all rows, then the document continues with the next group of columns, and each page header says which columns and which rows it is showing. Nothing is dropped silently — but a 200-variable dataset makes for a long document, which is another argument for the codebook section over the raw data table.
Why does it default to 1,000 rows instead of all of them?
Because a PDF is paginated. 40,000 rows is roughly 1,100 pages, which takes a while to build in a browser tab and is not a document anyone reads. You can switch to "All rows" whenever you want the complete export, and either way the cover page and every data page print "rows 1–N of M", so a truncated PDF can never be mistaken for the full dataset.
Is my file uploaded anywhere?
No. The .sav is parsed in your browser and the PDF is generated there too — the bytes never leave your device, which is why this works on confidential survey data and why there is no file size limit imposed by a server.