Analyze your ZIP.
safe · secure · no server · works offline · fast
…or just start typing at the cursor.
↓ scroll for about & FAQsafe · secure · no server · works offline · fast
…or just start typing at the cursor.
↓ scroll for about & FAQ
Drop a .zip and OmniViewer reports the archive’s technical
shape: how many files and folders it holds, the
total unpacked size against the size on disk, the
compression ratio and the percentage of space saved, whether it
uses ZIP64, and how many members are encrypted or are symlinks.
Then it breaks that down: the compression‑method mix (a well‑built archive deflates its text and stores its already‑compressed images), the largest file types by total bytes, the biggest individual members, and the full entry table with every size, ratio, CRC and mode. All of it comes from the archive’s index, so it is instant at any size and nothing is uploaded.
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 a .docx and you can browse to word/document.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 .war, .ipa, .whl, .xpi, .crx and .nupkg.
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.
It can list one but not decrypt it. A ZIP encrypts member contents, never its table of contents, so the names, sizes and structure are always readable and the AUDIT tab reports which entries are encrypted and whether they use modern WinZip AES or the legacy, cryptographically broken ZipCrypto. Extracting an encrypted entry is not supported.
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.