Is this ZIP corrupted?
safe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQsafe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQAn archive can look perfectly well‑formed and still be broken. The central directory is only what the archive claims: a half‑finished download, a bad disk or a truncated transfer leaves the index intact while the compressed data underneath it rots. Reading the listing cannot tell you the difference.
Verify does the expensive thing. Every member is decompressed with the browser’s own DEFLATE decompressor and its CRC‑32 is recomputed and compared against the value the archive recorded when it was written. A member that fails is named, with the reason — a CRC that disagrees, a deflate stream that will not decode, an entry that runs past the end of the file. A clean run tells you every byte is exactly what it should be.
Nothing is kept. Each member is streamed through the decompressor and discarded as it goes, so memory stays flat and the size of the archive is not a limit — a member far larger than your available RAM still verifies. It runs on your machine: no upload, no server, and you can cancel at any point. For the instant question — whether an archive looks dangerous rather than damaged — the audit answers from the index alone without decompressing anything.
It’s one lens on OmniViewer’s ZIP Viewer — Browse & Extract Online: drop a file and every tab is one click away. OmniViewer opens every file format, entirely in your browser — no upload, no server.
No. OmniViewer is a static page with no server-side processing: your archive is read directly by your browser, and every tab — entries, audit, stats and hex — runs locally in a Web Worker. The archive never leaves your computer, and neither does any file you extract from it.
Yes, and that is the point. The archive tells OmniViewer exactly where each member starts, so a preview or download reads only that entry’s compressed byte range, decompresses it with the browser’s built-in DEFLATE decompressor, and checks the CRC-32 the archive recorded. The other members are never touched, so pulling one file out of a 20 GB archive is as fast as pulling it out of a small one.
Effectively unlimited. Listing an archive needs only its index: a tail read to find the End of Central Directory record and one read of the central directory it points at — roughly 46 bytes plus the path per member. The compressed contents are never read, so the cost scales with the number of entries, not the size of the file. ZIP64 archives past 4 GB and past 65,535 entries are handled.
Yes. All of those are ZIP archives with a different extension and some required members inside, and OmniViewer detects them from their first four bytes rather than their name. Drop an .xlsx and you can browse to xl/workbook.xml and read it inline; drop an .apk and you can see AndroidManifest.xml, classes.dex and the resources; drop an .epub and you get its chapters. Same for .pptx, .war, .ipa, .whl, .xpi, .crx and .nupkg. A .docx is a ZIP too, but it gets its own Word toolkit — OmniViewer looks past the ZIP header for a word/ part and opens it there instead.
An entry name inside a ZIP is an arbitrary string that extractors treat as a file path, and nothing in the format stops it being "../../../etc/cron.d/backdoor". An extractor that joins the output folder with that name writes outside the folder — that is zip slip. The AUDIT tab flags any entry with a ".." segment, an absolute or drive-qualified path, or a backslash separator (which slips past sanitizers that only look for forward slashes), and lists the exact entries, so you know before you extract.
Yes, from the index alone. Every entry declares its uncompressed size, so the expansion is visible before anything is decompressed. The AUDIT tab flags entries that expand by more than several hundred times — ordinary data never does, but a run of one repeated byte compresses about 1030:1 — and flags an archive whose total declared output dwarfs its size on disk. It also reports entries whose offsets overlap, which is how the modern non-recursive bombs reuse one payload many times.
A ZIP stores every member’s metadata twice: once in a local header before the compressed bytes, once in the central directory at the end. Almost every tool lists from the central directory, but some extract using the local header — so a deliberate mismatch can show a scanner one file and an extractor another. This was the basis of the Android "Master Key" and Janus bugs. OmniViewer cross-checks a sample of entries and reports any disagreement in name, method, CRC or size.
Yes. A password field appears above the entry tree whenever the archive has encrypted members; type the password once and every locked entry previews, opens and extracts normally. Both schemes are supported — WinZip AES at 128, 192 and 256 bits, and the legacy, cryptographically broken ZipCrypto that older tools still write. A wrong password is reported instantly from the archive’s own verifier rather than from a failed decompression. Note that a ZIP encrypts member contents and never its table of contents, so names, sizes and structure are readable even before you unlock it — which is why the AUDIT tab can report the encryption scheme and strength of a file you have no password for. The decryption happens in your browser and the password is never stored or sent anywhere.
Stored (uncompressed) and DEFLATE, which together cover essentially every ZIP in the wild — DEFLATE is method 8 and is what over 95% of real entries use. Those two work because the browser ships a DEFLATE decompressor natively, so no compression library is needed. Entries using bzip2, LZMA, XZ, PPMd or Zstandard are listed in full with all their metadata, but marked as not extractable here.
Yes. A folder in a ZIP is only an optional zero-length member whose name ends in a slash, and plenty of archives omit them entirely — a member called src/lib/util.js with no entry for src/ at all. OmniViewer builds the tree from the path segments, so you always get a real folder view, and it rolls file counts and sizes up through the folders.