Drop a ZIP. Any size.
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
OmniViewer opens a .zip right in your browser. Drop the archive
and you get its complete contents as a folder tree: every
member with its real size, its packed size, how well it compressed, the
method used, its CRC‑32, its unix permissions and its timestamp. Click
preview on any entry and it is decompressed on the spot —
reading only that entry’s bytes — so you can read a manifest,
check a config file or look at an image without unpacking anything else.
There is no upload and no server, and the heavy work runs in a background
Web Worker so the page never freezes.
The reason it opens instantly, at any size, is the format itself: a ZIP keeps its table of contents at the end of the file. OmniViewer reads the tail, follows it to the central directory, and stops — the compressed payloads are never touched. Listing an archive costs two reads whether it weighs 20 KB or 20 GB.
A .docx, .xlsx or .pptx is a ZIP of XML
parts. So is an .epub e‑book, a Java .jar, an
Android .apk, a Python .whl, a browser extension
(.xpi, .crx) and a NuGet .nupkg.
OmniViewer detects them by their first four bytes — 50 4B 03 04,
Phil Katz’s initials — not by the extension, so all of them open in
this same toolkit, and you can read the XML inside a Word document or the
manifest inside an APK without renaming or extracting anything. Our
deep dive into the central directory and DEFLATE
walks the whole structure, with the field tables and real parsing code.
OmniViewer opens every file format; the ZIP toolkit sits alongside the other archive tools, powered by the same viewing engine as fastjsonviewer.com and hugecsv.com.
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.