Extract Zip File Online Free

How a ZIP is read: the directory at the end of the file

Opening a ZIP is mostly bookkeeping. The archive ends with a small record called the end of central directory, and that record points to the central directory just before it. The central directory holds one row per entry: filename, folder path, timestamp, compressed and uncompressed sizes, the method used, and the offset where the actual bytes begin. An unzip tool reads those last few hundred bytes first, then knows the entire contents without touching a single payload.

That layout is also why ZIPs behave the way they do when things go wrong. An interrupted download loses the tail of the file, the pointer disappears, and the archive cannot be listed at all, which is the failure this tool reports most often. Files written over a flaky network connection are the usual cause, and re-downloading fixes it in one try. The reader checks for that record before it does anything else, precisely so a broken file fails fast instead of producing a confusing partial listing.

Only after the directory is understood does the data get unpacked. Each entry's compressed bytes are run back through the algorithm named in its row, and the result is compared against the CRC checksum that was stored when the archive was written. Match, and the file is handed to you. Mismatch, and the entry is marked corrupt rather than delivered silently with damage inside.

Folder structure: what happens to paths when you download

Paths live in filenames inside the archive, as strings such as photos/2024/beach.jpg. The extractor creates each folder as it walks the string. That is the whole mechanism, and it is why a ZIP made on any operating system unpacks with its structure intact anywhere else.

The structure is preserved on the way out, too, with one important caveat about how browsers handle downloads. Saving a single file puts its name into your Downloads folder and drops everything before the last slash. Saving twenty files does that twenty times, and files that shared a folder name compete for it. The reliable way to keep a tree whole is to rebuild the archive, which is what the second download button does: every path goes back in exactly as stored.

There is a second reason to prefer the rebuilt archive: a re-zip re-compresses with deflate, so an archive that was stored uncompressed often comes back smaller, with the same contents inside. Check the status line for the new size before and after.

What extraction really does: byte-for-byte, or not at all

Decompression is the exact inverse of compression, not an approximation. When deflate ran at pack time, reversible patterns were written once instead of repeatedly; unpacking replays those instructions and rebuilds the original bytes. There is no generation loss, no re-encoding, and no quality decision. The picture that comes out of a ZIP is bit for bit the picture that went in, and so is the PDF, the spreadsheet and the signed contract.

The checksum is what turns "probably fine" into "certainly fine". Every entry carries a CRC32 value computed when the archive was created, and extraction recomputes it on the rebuilt bytes. Two different byte sequences producing the same CRC is astronomically unlikely in normal use, so a passing check is as close to a guarantee as file transfer gets.

What we actually tested

This page makes specific claims, so here is how they were checked. The reader was exercised as a pair with the writer in a Node harness: an archive built by our ZIP maker was read back entry by entry, and the decoded bytes matched the inputs exactly, with compressed sizes, method numbers and uncompressed sizes reported correctly. A stored (uncompressed) archive round-tripped the same way, which covers method 0 independently of method 8.

On the failure side, we deliberately fed the reader non-archive bytes and an incomplete tail. Both were rejected with a descriptive error naming the missing end-of-archive record, which is the message the page surfaces verbatim rather than inventing a friendlier fiction. Passing an empty file list to the rebuild button was rejected too, because there is nothing honest to write into an archive with no entries.

In the browser, we opened DevTools, went to the Network tab, and extracted a ZIP: the only requests were the page's own HTML, CSS and JavaScript. The path runs from File.arrayBuffer() through the reader into Blob downloads, all inside the tab. We also checked the rebuild path with a folder-heavy archive to confirm paths survive the second trip byte for byte, and confirmed that an unsupported method surfaces its number in the status line instead of a generic failure. What we did not do: publish benchmark timings from synthetic suites. The numbers on this page are the ones your own archive reports.