GZ to JSON — describing one decompressed stream as a single entry
A ticket sometimes needs the decompressed size of a gzipped export before anyone opens it. This route gunzips a single stream inside the browser tab and emits a JSON inventory describing that payload as one entry: name, kind, uncompressed byte length, counts and extension grouping. There is no entry table in a .gz file, so the entry is derived from your input filename — the gzip header's stored name and timestamp are not reproduced.
The gzip layer is removed; the gzip header name and mtime fields are not carried over.
Processed on your device. Files aren’t sent anywhere.
Describing one stream as data
Native streaming decompression unwinds the gzip stream and validates its checksum; expansion is bounded during the read, so a stream that inflates aggressively is stopped rather than filling memory.
- The output has exactly one entry, because a gzip stream is a single payload.
- That entry's bytes value is the decompressed length, not the compressed file size.
- The entry is classified as a file; there are no directories in a gzip stream.
- Both text and binary payloads can be described. JSON reports their byte length without embedding the payload or claiming to recognise its type.
- Nothing is uploaded; the JSON is a file you download.
Reading the JSON
The same schema the archive inventory routes use, filled with one entry instead of many.
| Field | Value for a .gz stream |
|---|---|
| source | your input filename |
| container | gz |
| entries | one entry: name, kind file, decompressed bytes, target null |
| counts.entries / counts.files | 1 and 1 |
| counts.directories / symlinks / other | 0, 0, 0 |
| total payload size | the decompressed payload length |
| byExtension | file count by the extension of the derived name; no-extension when absent |
| note | a generic caveat that the inventory describes the table rather than file contents |
Where the entry name comes from
The gzip header may store an original filename and a timestamp; some writers set them, others leave them empty. Neither is used here. The entry name is derived from the input filename you dropped in, so a file called export.gz produces an entry named export.
That makes the inventory predictable across tools that write gzip headers differently, and it means renaming the input before conversion changes the reported name.
What the counts mean for a single stream
With one entry, counts are a summary rather than a comparison: counts.bytes is the number you wanted recorded, and the other fields confirm the shape — one file, no directories, no symlinks, no other entry types.
The symlink and other counters are zero because this route models a gzip payload as one regular-file entry, not because it inspected the payload for archive types. There are no contents, hashes, modification times or compression ratios in the report.
Single-stream inventory questions
Is this an archive listing?
Does the JSON report the compressed size?
Does the gzip header's filename appear in the output?
Can this describe a gzipped binary?
Recording the stream as a record
The compressed input ceiling is 12 MiB. The decompressed payload must fit the 8 MiB single-member bound and the 60x expansion ratio. The larger shared total does not override that single-payload limit.
- Drop the .gz file into the studio — one gzip stream, up to 12 MiB.
- Choose JSON as the target.
- Let the decompression finish; the checksum is validated and expansion is bounded.
- Read counts.bytes for the decompressed length and paste it into the ticket.
- Check byExtension if the filename matters to the report.
- Treat the extension as a naming hint only. The JSON does not identify a payload format, verify its application-level structure or decide whether it is safe.