Extract one file from a 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 & FAQYou need one file out of a big archive, and every tool wants to unpack the whole thing first. OmniViewer doesn’t. A ZIP records exactly where each member begins, so when you click download on an entry it reads only that entry’s compressed byte range, inflates it with the browser’s own DEFLATE decompressor, and checks the CRC‑32 the archive recorded — so a corrupt member is reported rather than quietly saved. The other members are never touched.
That means pulling one file out of a 20 GB archive costs about the same as pulling it out of a 20 KB one, and it all happens on your machine: no upload, no server, nothing to install. Text and image entries can be previewed inline first, so you can check you have the right file before you save it. Stored and DEFLATE entries extract; bzip2, LZMA, XZ, PPMd and Zstandard members are listed in full but marked as not extractable here, and encrypted entries cannot be decrypted.
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.