Open a ZIP in your browser and read what is inside it before extracting anything. The listing comes from the archive's own index, so nothing is decompressed until you ask for a file — and the three things worth knowing about an archive you did not make are reported up front: entries that would escape their folder, entries that need a password, and entries that expand far enough to fill a disk.
Step by step
01Open the archive
Drop a .zip anywhere on the page. Its index is parsed in this tab — nothing is uploaded and nothing is decompressed yet.
02Read the listing
Every file with its real size, how much compression saved, and when it was last modified. Filter by name when the archive is large.
03Check what the archive is doing
The Checks tab names entries whose paths climb out of the extraction folder, entries locked with a password, and anything expanding far enough to be a decompression bomb.
04Take the files you want
Download an entry and only that entry is inflated. Pulling one file out of a large archive costs one file's work.
Worked example
What the index says before a single byte is decompressed.
Given
The Checks report
Escapes the extraction folder 1 entry
../escaped-config.json
Expands to 21 KB from 14 KB
Encrypted entries None
Read without decompressing 6 entriesThe dangerous entry was identified from the index alone. Every desktop extractor would have shown it as an ordinary row and written it wherever its name pointed.
Why this one
The index is at the end, and it costs nothing to read
A ZIP keeps a central directory at its end listing every entry with its name, sizes, timestamp and flags. Reading it means seeking to the last few hundred bytes — so listing a two-gigabyte archive is as fast as listing a small one, and no compressed data is touched at all.
Zip slip is old and still works
An entry named ../../.ssh/authorized_keys is legal in the format. Extractors that join that name onto a destination folder write outside it, and this has produced real vulnerabilities in many libraries. Nothing here writes to your filesystem, but an archive carrying such a name is telling you something, and almost no tool shows it as anything other than a normal row.
A password does not hide the file names
Standard ZIP encryption covers the contents of entries, not the central directory. So a locked archive still tells anyone who opens it exactly what files it holds and how big they are. That surprises people who used a password expecting the listing to be private too.
Compression ratio is a signal, not a verdict
A file expanding hundreds of times over is either very repetitive or deliberately hostile, and the archive cannot tell you which. What it can do is give you the number before you spend the disk space, which is the part every other extractor leaves out.
One file at a time
Downloading an entry inflates that entry alone. Pulling a single config file out of a large source archive does not require unpacking the rest, and nothing is ever written to your machine except the file you asked for.
The judgement call
Three findings, three different responses.
An entry named ../something
Do not bulk-extract
The name points outside the folder you would unpack into. Extractors that join the name onto a destination path will write it there, overwriting whatever is at that location. Take individual files you trust instead.
An entry expanding 500× or more
Check before unpacking
Highly repetitive data compresses this well legitimately — a sparse disk image, a log full of one repeated line. It is also what a decompression bomb looks like. The point is to know the number before you commit the disk space.
Encrypted entries
Use a desktop tool
This reader cannot supply a password. Their names and sizes are still listed, because a ZIP does not encrypt its index — which is itself worth knowing if you assumed a password hid the contents.
An ordinary archive with no warnings
Take what you need
Download individual entries; each is inflated on its own. There is no need to unpack the whole thing to read one file.
A .rar or .7z file
Not supported
Those are different formats with different compressors. This reads ZIP, which is what almost everything on the web produces.
Reference
FAQ
Yes — that is what this does. The archive is read in your browser, its index parsed in the page, and entries inflated locally when you download them. Nothing is sent anywhere, there is no account and no size limit, and it keeps working with the network disconnected.
A ZIP stores an index — the central directory — at the end of the file, listing every entry with its name, compressed and uncompressed size, timestamp and flags. Reading that index requires no decompression at all, which is why opening a very large archive to see inside it is instant.
An entry whose name contains .. or starts at a filesystem root would be written outside the folder you extract into. Many extractors do exactly that, which is a long-standing vulnerability known as zip slip. Nothing here writes to your disk, but the presence of such a name says the archive is not to be trusted with a bulk extraction.
No. Encrypted entries are listed and clearly marked, but this tool cannot supply a password, so their contents stay locked. You will need a desktop tool for those. Note that the file names and sizes are visible regardless, because ZIP encryption does not cover the index.
No. Those are separate formats with different compression, and this reads ZIP only. If a file will not open, check whether it is actually a .rar or .7z with the wrong extension — the tool will say so rather than failing vaguely.
There is no imposed limit; the practical bound is your own memory, because the archive is held in the tab. Listing is cheap at any size since only the index is read. Extracting a single very large entry is what needs room.
Keep going
EXIF viewer & remover
Inspect what a photo carries before you share it.
CSV to JSON
Convert a data file you pulled out of an archive.
JWT decoder
Read a token's claims locally, without pasting it into a website.
Base64 encoder & decoder
Decode an embedded payload without a round trip to a server.