ZIP to JSON — describing a delivered bundle as data instead of unpacking it
A ZIP arrives as delivery and the first question is not how to unpack it but whether it contains what you expected. This route reads the archive entry by entry in the browser tab and emits a JSON inventory: names, kinds, uncompressed payload lengths, counts and a by-extension grouping. It is a description of the container, not a copy of the files inside, and nothing is uploaded or extracted to folders.
ZIP metadata outside the entry table (comments, extra fields, timestamps with sub-second precision) is not rewritten.
Processed on your device. Files aren’t sent anywhere.
Reading the bundle without unpacking it
The converter decompresses and validates ZIP members in memory, then builds a report of their names, kinds and lengths. Payloads are omitted from the JSON, and member files are never automatically extracted into folders.
- Every entry is listed with its name and kind — file or directory.
- File entries carry their uncompressed payload length, not the compressed size stored in the archive.
- Directory entries are included, so folder structure is visible.
- Entry order follows the archive by default; choosing sorted-by-name reorders the inventory only, never what was read.
- Unsupported entries stop the read with a named error rather than appearing as an empty row.
The inventory schema, field by field
The output is deliberately small and predictable. Each field has one meaning, and there is no guessing about what a number represents.
| Field | What it holds |
|---|---|
| source | the input file name |
| container | the archive type that was read |
| entries[] | name, kind, uncompressed bytes, and target (null for supported entries) |
| counts | entries, files, directories, symlinks, other and total bytes |
| byExtension | regular-file counts grouped by filename extension, not by detected contents |
| note | a short statement about what the inventory represents |
What the inventory deliberately omits
There are no file contents, no hashes, no modification times and no compression ratio in the output. That is a design choice: contents would turn an inventory into a data dump, and a ratio would invite claims the reader cannot verify for every entry.
The symlinks and other counters remain zero because those ZIP entry types are unsupported. Encryption, unsupported compression, split or ZIP64 storage, unsafe or duplicate names, invalid encoding and damaged data also stop the read instead of returning a partial inventory. TAR-specific PAX and GNU headers are not ZIP entry types.
Using the inventory to compare deliveries
Two deliveries of the same project can be compared by their counts and extension grouping before anyone unpacks either one.
Directory counts cover explicit directory records only. A bundle can store nested filenames without separate folder entries, so compare full paths as well as counts when reviewing a delivery.
- Convert the first .zip to JSON and save the output.
- Convert the second .zip the same way.
- Diff the counts block: entries, files and directories tell you whether one bundle has extra folders.
- Read byExtension to spot unexpected build output, such as a spike in compiled artefacts.
- Compare total bytes to see whether one delivery carries larger payloads.
- Only unpack once the inventory matches what the delivery was supposed to contain.
Limits that shape the inventory
- Input is capped at 12 MiB, one file at a time.
- At most 200 entries are read, and each member is capped at 8 MiB.
- The combined uncompressed payload of every member must stay under 32 MiB, and a bundle that expands more than 60 times its compressed size is stopped while it is being read.
- The inventory describes the archive; it does not extract members to folders, restore metadata or identify malware.