Open a ZIP archive in this tab and download the files inside individually. The archive is read on your device, so nothing is sent anywhere and there is no queue to wait in.
Runs in your browser. Nothing is uploaded.
A ZIP file is a set of compressed members followed by a directory at the end listing what is inside and where each member starts. Opening one here parses that directory, then runs every member back through DEFLATE to recover the original bytes, and hands you a list with a download beside each file. All of it happens in the page: the archive is read through the browser's file API, and the decompressed contents live in the tab's memory until you close it.
Everything is decompressed at the point you choose the file, not at the point you click a download. A 725 KB archive holding 300 text files was unpacked and listed in 69 milliseconds, and a 20.5 MB archive of three large files took 100 milliseconds. That eagerness is what makes each download instant afterwards, and it is also the tool's main constraint: an archive whose contents will not fit in available memory will not open, because there is no streaming path that writes members to disk as it goes.
Choose a ZIP file
The same questions a security review would ask, answered plainly.
What a local extractor gives you that an upload-based one cannot.
You get one row per member with its own download, so you can take the one document you needed out of a forty-file archive without unpacking the rest onto your disk.
A 20.5 MB archive opened in 100 milliseconds. There is no transfer to sit through first, which on a typical connection is most of what other tools make you wait for.
Exports from a payroll system, a backup of a case folder, a bundle from a client. The contents stay on your machine, so using this is not a decision anyone needs to approve.
A locked-down work laptop, a Chromebook, a borrowed machine. Anything with a current browser can open an archive here without admin rights or software.
There is no upload step and no server to receive one. The page loads once, then all work on your archives happens in local JavaScript.
No daily limits, no per-file ceilings imposed by a server tier, no watermarks, and no account. The practical limit is your own device's memory.
How long real archives take, and where the time actually goes.
The everyday case: an export or a shared bundle with real folder structure.
Archive
724,948 bytes, 300 text files in nested folders
Listed
300 downloadable files, 69 ms
Every member was decompressed before the list appeared, which is why each download is instantaneous afterwards. The folder paths are kept in the filenames so you can tell two files called notes.txt apart.
Where the memory cost of unpacking everything up front is easiest to see.
Archive
20,507,979 bytes, one PNG and two PDFs
Listed
3 downloadable files, 100 ms
Three members took longer than three hundred did, because time here follows the number of bytes to decompress rather than the number of entries. The uncompressed contents occupy memory for as long as the tab is open.
Real files, real numbers, and the machine they were run on.
| Scenario | Input | Output | Time | Notes |
|---|---|---|---|---|
| 300-entry archive, all entries decompressed and listed | 724,948 bytes | 300 files listed | 69 ms | nested folders preserved in paths |
| 20.5 MB archive of three large members | 20,507,979 bytes | 3 files listed | 100 ms | time follows bytes, not entry count |
How this was measured: Measured by driving this page in headless Chrome 152 on an Apple M4 Pro running macOS 15.5, on 2026-09-17. The fixture is handed to the page's own file input, the page's own button is pressed, and the figure recorded is the size of the file the page produces. Timings come from a warm page on a fast machine with no network involved, so treat them as a floor rather than a typical result.
Open this page and choose the archive. ChromeOS can open ZIPs through the Files app, but that mounts the archive as a temporary drive and copying anything out of it is fiddly. Extracting here gives you an ordinary download per file instead.
You do not need either. Windows and macOS can both open a plain ZIP natively, and when you are on a machine where you cannot install anything, this page does the same job in a tab with no admin rights required.
Choose the archive, find the row you want, press Download on that row alone. Nothing else is written to your disk, which is quicker than unpacking a hundred files into a folder and then deleting ninety-nine of them.
The same way as anywhere else, with the caveat that the whole archive is decompressed into memory. A few megabytes is fine on a phone; a large backup is likely to fail where the same file would open on a laptop.
Save the attachment, then select it here. Because the archive never leaves your device, this is also a reasonable way to look inside an unexpected attachment without giving a copy to a third-party service.
Use the preview tool instead. It reads the archive's directory and lists the contents without decompressing any member, which on the 20.5 MB archive took 54 milliseconds against 100 for a full extract.
Plenty of corporate laptops block installers and the well-known archive sites at the same time. A page that unpacks locally works inside both restrictions without an exception being raised.
Design assets, source files and document bundles usually arrive zipped. Opening them without a round trip through someone else's server keeps a confidentiality agreement simple to honour.
Account exports, payroll runs and case bundles come out as archives full of personal data. These are exactly the files that should not be handed to a free web service, which is usually why people go looking for one.
Lecture packs and assignment templates get distributed as one file. A student on a shared or managed machine can open them without needing anything installed.
Once this page has loaded, unzipping keeps working with the network off. It is genuinely useful on a plane, and it is also the simplest proof that the archive is not going anywhere.
Listing the contents of a suspicious archive without running anything is a reasonable first look. Note that this does not scan for malware; it only shows you what is in there.
Four real boundaries, including the one people hit most often.
An encrypted ZIP is refused when the file is selected, with no prompt and no partial listing, because the library underneath does not implement ZIP encryption at all. Tested with an archive made by zip -e. Decrypt it with a desktop tool first.
Those are different container formats with different compression, and nothing here can read them. A file that ends in .zip but was actually produced as a RAR will fail to open too.
There is no streaming extraction, so the uncompressed contents of the whole archive have to fit in the tab. Multi-gigabyte backups are the wrong job for this page, and a phone gives up considerably earlier than a laptop.
There is no download-all button, and saving a file puts it straight in your downloads folder rather than recreating the folders it came from. For a forty-file archive that is tedious; the folder structure is still visible in each name.
No, and it is straightforward to confirm. An archive is the easiest case to check, because a real upload of a 20 MB file would take visible seconds: watch the transfer indicator while you select one and there is nothing to see, since the bytes never leave the disk. Disconnecting from the internet before you open an archive is the decisive version of the same test.
No. Selecting one produces an error rather than a password prompt, because the extraction library has no support for ZIP encryption and rejects the file before it reads the contents. You will need a desktop application such as the built-in Archive Utility, 7-Zip or WinRAR to decrypt it, after which the unprotected copy opens here normally.
No, only ZIP. RAR and 7z are separate formats with their own compression algorithms, and a .tar.gz is two layers that this does not unwrap. Renaming the extension does not help, because the contents are read rather than the name.
There is no fixed cap, because nothing here enforces a tier. The practical limit is memory: every member is decompressed when you select the file, so the uncompressed total has to fit in the tab. Tens of megabytes is routine on a laptop and much less so on a phone.
Because the work is done then rather than later. All the members are decompressed as soon as the archive is selected, which is why every download afterwards is instant. On a 20.5 MB archive that initial pass took 100 milliseconds.
In the listing, yes: each row shows the full path so docs/section-4/notes.txt is distinguishable from docs/section-9/notes.txt. In your downloads folder, no. Files are saved individually by name, because a browser download cannot create directories.
Not from here. Each file has its own download and there is no bulk option, so an archive with many members is genuinely tedious to unpack completely. For that case a desktop extractor is the better tool, and this one is better when you want two files out of forty.
No. DEFLATE is lossless, so the bytes that come out are exactly the bytes that went in when the archive was made. A document, an image or an executable is recovered identically, including its original timestamp where the archive recorded one.
No. This reads the container and shows you what is inside it; there is no malware scanning of any kind. Seeing a filename is not the same as the file being safe, and an unexpected archive is worth treating carefully however you open it.
They disappear. The decompressed contents only ever existed as objects in the page's memory, so closing the tab discards them. Anything you pressed Download on is already saved in your downloads folder and is unaffected.
Download it to your device first, then select it. The file picker reads local files, so a link to a file in Drive or Dropbox is not something this page can open directly.
Yes, after the page has loaded once. The code that reads archives is already in the browser by then, so you can disconnect and keep opening files. Only reloading the page while offline depends on the browser cache still holding it.
There is no limit imposed by us, because there is no server tier to enforce one. The real constraint is your device's available memory, since the whole file is held in RAM while it is processed. Very large files are slower on phones than on a laptop.
No. There is no sign-up, no email, and no usage tracking tied to an identity. The tool works the first time you open it.