Game save to CSV, for Unreal saves.
Drop an Unreal Engine .sav file and read what is inside it — every property, as a table you can export to CSV or JSON. Runs in your browser; the file is never uploaded.
Two different files share the .sav extension
A .sav file is either an IBM SPSS Statistics dataset or a game save, and the two have nothing in common beyond those four characters. They are told apart by their opening bytes: an SPSS file starts with $FL2 (or $FL3 for the compressed .zsav variant), while an Unreal Engine save starts with GVAS.
This page reads the second kind. If you have a statistics dataset from SPSS, R or Stata, the SPSS .sav to CSV converter is the one you want — it produces a normal rectangular table of cases and variables rather than a property list.
What the game save to CSV export contains
An Unreal save is a tree of named properties, not rows and columns, so the export flattens it: one line per leaf value, with the full path to that value in the first column. A nested inventory entry becomes PlayerState.Inventory[0].ItemId, which sorts and filters cleanly in a spreadsheet and stays unambiguous when two different structures happen to use the same field name.
The JSON export rebuilds the same paths back into nested objects, which is usually easier if you are feeding the result into a script rather than opening it in Excel.
That flattening is the whole reason a game save to CSV conversion is worth doing at all: in the raw file a value like a coin count sits somewhere inside a nested property tree with no way to search it, and once it is a row in a spreadsheet you can sort, filter and diff two saves against each other.
Where the game save to CSV reader stops, and why that is safe
Every property in the format declares its own byte length before its contents. That detail is what makes partial reading trustworthy: when the reader meets a property type it does not decode, it can skip exactly that many bytes and pick up cleanly at the next property instead of losing its place and producing plausible-looking nonsense for the rest of the file. Those skipped properties appear in the output marked (not decoded), and the count is shown above the table — an export that quietly omitted them would be worse than one that says so.
Compressed container formats used to be the whole gap. One of them is now closed: a Palworld save is a zlib-compressed GVAS behind a twelve-byte header, and the reader unwraps it before parsing, so those files convert here directly. The header names the codec, and the one variant that stays out of reach says so plainly — a save compressed with Oodle (marked PlM rather than PlZ) cannot be unpacked by any browser tool, because Oodle is proprietary and has no open implementation.
Other games' containers remain a gap. ARK and Satisfactory each wrap their GVAS in a different game-specific archive, so those files still do not open with GVAS and are rejected up front rather than half-read.
Questions
Which .sav files does this read?
Unreal Engine saves — the ones whose first four bytes are the letters GVAS — and Palworld saves, which are a GVAS behind a zlib container that the reader unwraps for you. Drop the file in and it tells you immediately which it is; it checks the actual bytes rather than trusting the extension, because both game saves and SPSS data files are named .sav and are otherwise unrelated formats.
Does my Palworld save work here?
Yes, if it is one of the zlib-compressed ones — that is the usual kind, and it covers Level.sav, LevelMeta.sav, WorldOption.sav and the per-player files. Palworld puts a twelve-byte header in front of the compressed GVAS, so the file does not begin with GVAS and used to be rejected; the reader now reads that header, decompresses the save and parses what is inside. The exception is a save compressed with Oodle (its header says PlM instead of PlZ). Oodle is proprietary with no open decompressor, so no browser tool can unpack one — the reader says so rather than failing vaguely.
Why does my ARK or Satisfactory save not work?
Those games wrap the GVAS data in their own container formats, which are different from Palworld’s and are not read here yet, so the file does not begin with GVAS and cannot be parsed. You would need to unpack it first with a tool built for that specific game, after which the extracted save can be read here.
What do the CSV columns mean?
Three columns: path, type and value. Path is the property name, with nested structures written as dots and array items as bracketed indexes — PlayerState.Inventory[0].ItemId, for example. Type is the Unreal property type such as IntProperty. Value is the decoded value as text.
Some rows say "(not decoded)". What happened?
A property whose type this reader does not decode yet — maps are the common case. Every property declares how many bytes it occupies, so an unknown one is skipped precisely and the rest of the file still reads. Those rows stay in the export, marked, rather than being dropped silently, and the count is shown above the table.
Is my save file uploaded anywhere?
No. The file is read in your browser with JavaScript and never leaves the device — the same as every other converter on this site. There is no account and no server-side processing step.
Can I edit the save and write it back?
No. This reads and exports only. Writing a modified save back requires re-encoding every property exactly as the game expects, and a save that is subtly wrong can corrupt a playthrough — so this tool does not attempt it.