Extract a ZIP file
Every operating system can unzip. What they cannot all do is show you what is inside first, tell you an entry's stored checksum disagrees with its data, or warn you that an entry's path is trying to write outside the folder you chose.
This reads the ZIP central directory directly, so you get the container's own metadata: compression method per entry, stored CRC-32, exact compressed and uncompressed sizes, encryption flags and Zip64 extents. Then it extracts, checking each entry's CRC as it goes.
The archive is read by code running in this tab. It is not uploaded, not queued on a server, and not seen by anyone but you — which also means there is no size limit imposed from outside, only what your own device can hold.
- Step 1Drop one or more .zip files.
- Step 2If any entry is encrypted, enter the password for that archive — it stays in this tab and is not stored between visits.
- Step 3Extract everything or a selection, as separate files or one bundled ZIP.
Drag archives here
.zip— or anything else, and the format will be identified from the file’s own bytes. Files stay on this device.
What this page will not do
Every limit below is a real one, checked against real archives. None of them are upsells — there is no paid tier, and nothing here gets better by signing in.
- Passwords work for ZipCrypto and WinZip AES-128/192/256. The WinZip “strong encryption” extension is not supported by any browser-side reader and is reported as such.
- Split ZIP sets (.z01, .z02 …) are refused; the spanning marker is detected and explained.
- Deflate64, PPMd and a few rare methods are not decoded by the fast JavaScript path; where they appear, the archive is routed to the WebAssembly engine, and if that cannot read them either the entries are named as failures rather than dropped quietly.
- An entry whose data does not match the CRC-32 stored in the archive is reported as damaged and left out, instead of handing you a corrupt file that looks fine.
If it did not work
“Checksum mismatch” on one file
Why: The decompressed bytes do not match the CRC-32 the archive itself records. The archive is damaged.
Do this: Get a fresh copy. Other entries in the same ZIP are usually fine and are still extracted.
The password is rejected
Why: Wrong password, or the archive uses the unsupported strong-encryption extension.
Do this: Check for a trailing space when pasting. The message distinguishes a wrong password from an unsupported scheme.
File names are mojibake (“╤ä╨░╨╣╨╗”)
Why: The ZIP stores names in a legacy code page without setting the UTF-8 flag.
Do this: This is handled: the Info-ZIP Unicode Path field is read when present, and otherwise names that are valid UTF-8 are decoded as UTF-8 rather than as CP437. If a name still looks wrong the archive used a code page that cannot be identified from the file.
“Entries try to write outside the output folder”
Why: A zip-slip attempt: absolute paths, `..` segments, or Unicode look-alikes of them.
Do this: Those entries are blocked and named. Treat the archive as untrusted; extract the rest if you still need it.
Questions
Can it open password-protected ZIPs?
Yes, for ZipCrypto and WinZip AES. The password is used inside this tab only — it is never sent anywhere, never written to storage, and never included in a manifest.
What is the largest ZIP it can handle?
Zip64 is supported, so the format itself is not the limit; your device's memory is. The archive has to fit in the tab, and the expanded contents have to fit alongside it. Budgets are shown before extraction starts.
Why does it show a CRC for each file?
Because ZIP stores one, and comparing it against what actually decompressed is the only way to know an entry is intact. Most unzip tools check silently and some do not check at all.