ZIP to TXT — a manifest you can paste into a ticket instead of unpacking the archive

Sometimes the job is not to convert files but to report what a bundle contains: a delivery note, a support ticket, a changelog entry. This route reads the ZIP entry by entry in the browser tab and writes text lines naming each entry, its kind and its uncompressed byte count. It is a manifest, not the unpacked payload of your files, and nothing is uploaded.

ZIP metadata outside the entry table (comments, extra fields, timestamps with sub-second precision) is not rewritten.

Drop files here or Choose files ZIP, up to 12 MB

Add a file to start.

Processed on your device. Files aren’t sent anywhere.

No sign-up. Nothing to install.

What each listing line contains

One line per entry, in archive order by default, or sorted by name if the note needs an alphabetical manifest.

Field	Meaning
name	the full member path as stored
kind	regular file or directory
bytes	uncompressed payload length — what the file would be once unpacked

The character cap and the truncation marker

A listing is capped at 200000 characters. If the archive is large enough to exceed that, the output ends with a marker stating that the listing was truncated, rather than stopping silently. A truncated manifest is honest: you know entries are missing.

For a bundle whose listing does not fit, the JSON inventory carries the same entries as structured data, which is easier to filter programmatically than a long text block.

Before you paste the manifest

Is the TXT output the contents of the files?

No. For ZIP archives the text output is a listing of entry names, kinds and uncompressed byte counts. File payloads are not included.

What happens if the archive has thousands of entries?

An archive with more than 200 entries is rejected before a manifest is returned. For an accepted archive with unusually long names, the separate 200000-character output cap can still truncate the listing and add a marker.

Why does a valid-looking archive get rejected?

Unsupported entry types and unsafe paths stop the read: symlinks, hardlinks, special files, ZIP64, split or encrypted ZIP, traversal or duplicate paths and non-UTF8 names are refused rather than listed.

Is this the same as gzip to text?

No. A gzip stream route decompresses a single text payload and returns that payload. A container route returns a listing of entries.

Turning the listing into a delivery note

A photo-album or project bundle often needs a short human-readable summary attached to it before anyone unpacks it.

Send the .zip to the archive studio; it takes one file at a time and rejects anything above 12 MiB.
Choose TXT as the target and pick entry order: archive order or sorted by name.
Copy the lines that matter into the ticket or delivery note.
Check for a truncation marker before quoting the manifest as complete.
Mention that byte values are uncompressed sizes, so a reader does not compare them with archive sizes.
Unpack the archive separately when you need the actual file contents.

The manifest answers 'what is in the bundle' without answering 'what is in the files'.
Why a listing route exists at all

What the listing does not do

It does not extract members to folders or automatically write individual member files into folders.
It does not include file contents, hashes or modification times.
Timestamps, permissions, owners, comments and extra fields are not brought back.
It does not identify malware. Unsupported ZIP variants, encryption, symlinks or Unix special files, invalid encoding, unsafe paths and damaged data reject the read; ordinary files are not analysed for malicious contents.
Expansion is bounded during streaming decompression: 200 entries, 8 MiB per member, 32 MiB expanded total and a 60x ratio.

More sharing options